[KLUG Members] New BSware-PRO this week with XFS 1.0.1

[Adam Tauno Williams]

>You must understand that no current filesystem is "the best."  They
>all serve different niches.  E.g.:

Agree.
 
>Ext3 -- evolutionary, "minimum change" approache

IMHO,  an evolutionary dead end.

>XFS -- port from Irix, maximum compatibility and features
>JFS -- port from OS/2-AIX (although missing AIX features)

JFS for Linux is not ready for prime time.

>ReiserFS -- ultra-revolutionary, the "next generation" in UNIX
>filesystems

Respectfully disagree that reiserfs is the "next generation."  But I
think it contains bits and pieces of future filesystes,  such as the
database/hashed tables vs. inode lists.  Some of these have even been
rolled into experimental versions of Ext3 and shown to provide a big
performance win.  Reiserfs is the future of filesystems in the same
sense that CODA/GFS/AFS is the future of NFS.
 
>So ReiserFS is great for small files.  It also doesn't use a
>traditional inode-meta data (i.e. file attributes, information,
>permissions, etc...) structure, but puts them all in a
>B-Tree/database at a centralized location.  This also means file
>deletion is very fast.  So ReiserFS rules at various applications,
>especially the /tmp and /var filesystems, Squid (the web cache),
>etc...  And Namesys has a grant from DARPA to add various features

Squid on Resierf is indeed a big win.

>I don't know much about IBM's JFS, but it seems to lack a lot of
>features and compatibility compared to XFS at this point.  And it's
>not as easy to install as ReiserFS (Mandrake, SuSE, others) or XFS
>(if you like RedHat).

IBM's port of JFS to Linux is not complete,  in part they wanted to
watch what angle acls, etc... are going to take in Linux.  Each fs
implementing an interface for itself is just plain dumb.  The POSIX
compliance of XFS, now becoming commonplace in the Linux field,  and the
support of this API by Samba will probably move this along.

>Again, more opinions.  If you want the "ultimate" in "evolution"
>from Ext2, then Ext3 is what you want.  Ext3 was "reliable/stable"
>in full-data journaling almost the day it came out (I've been
>running Ext3 0.0.2f in kernel 2.2.16 for over 18 months, 0 data loss
>and it was even able to recover from physical disk errors!).  And it
>drops down to a full Ext2 fsck if anything is wrong with the
>journal.  Unfortunately, Steve Tweedie, the maintainer of Ext2/Ext3,
>is screwing around with both performance and meta-data journaling in
>kernel 2.4.  IMHO, if I wanted performance and meta-data journaling,
>I would go with another JFS.  As such, you cannot even say Ext2 is
>"reliable/stable" in kernel 2.4.x yet!

Ext2 is dead.  Good for things like /usr, etc... where bieng "standard"
and "safe" is a win,  and performance doesn't matter all that much (all
the parts your using end up in RAM anyway).  Ext3 should stop thrashing
about and get on with the process of self-termination.

>then mix in select patches (especially various NFS/VM ones).  For
>those, like me, that trust RedHat's well tested and patched kernels
>(hence why the "latest" is only 2.4.3), XFS's "official releases"
>(like 1.0.1) are based on RedHat's kernel RPMs.  And given the
>application of XFS -- large volume, heavy utilization, combo NFS-SMB
>file servers, the focus and development is on and for file serving.

My advice, unless someone really knows kernel oddities,  is to use a RH
kernel.

>Ext2 -- no JFS, NFS clean, full quota, "beta" ACL
>Ext3 -- meta/full JFS, NFS clean, "beta" quota, "alpha" ACL
>ReiserFS -- meta JFS, requires NFS workarounds, "alpha" quota, no
>ACL yet (v4?), very extensible/non-traditioanl features
>XFS -- meta JFS, NFS clean, full quota, POSIX ACL
>JFS ** -- meta JFS, NFS okay, no quota, no ACL

What about large file support (>2Gb)?  I know XFS does this handily,
and I think ext2 does it in failry recent kernels.  But I haven't read
anything about large files and Reiserfs,

If filesystem performance is important,  don't forget to focus a little
attention on both your hardware (all controllers and drives are NOT
equal), and your kernel parameters.  These can make as big a, if not
bigger, performance diffrence than your filesystem.