[Dvdrtools-users] Re: Linux filesystems (not trying to start a flamewar) -- WAS: 4GB "limit" is 32-bit POSIX

[Bryan J. Smith]

On Wed, 2003-01-01 at 21:53, Florin Andrei wrote:
> That, and also the fact that it's significantly faster than the other FS
> when it comes to writing/reading from/to very large files, possibly from
> several simultaneously and/or on SMP systems.
> I'm not saying it's better than other FS always: ReiserFS has a
> noticeable advantage when you have many small files, and of course Ext3
> has the kickass data=journal mode.
> But for multi-GB files, XFS fares better: video captue, generally any
> kind of video stuff, mastering ISO images, etc.

SGI designed XFS specifically for optimized video and data processing. 
ReiserFS has its focus.  Ext3 has the unique option to do full data
journaling, which is nice if you have a nice, large NVRAM PCI card (ala
NetApp-like).  And I don't know IBM was thinking when they ported JFS
from OS/2 instead of their UNIX flavor AIX.

IMHO, and maybe it's because I'm used to supporting production file
servers, _maturity_ is a _huge_ factor to me.  I have used Ext3, XFS and
ReiserFS pretty extensively.

First off, people _wrongly_ think journaling is about data integrity,
with exception of "full data" journaling with a NVRAM board, it's
_not_.  It's about avoiding a full fsck.  That's why if there is a
"problem" with a journal, it should _always_ be discarded.

As such, Ext3 is basically Ext2, 100% structure-wise.  If Ext3 detects a
single problem with its journal, it breaks down to a full Ext2 fsck. 
Yeah, my server might not be available for a hour, but my users won't be
corrupting the filesystem.  Ext2 has a 7 years proven fsck.  I've even
recovered from physical disk errors, as well as a RAID miscue.  Ext3
continues to add performance and other features, including POSIX EA/ACL
support.  NFS worked "off-the-bat" and quota support issues were worked
out rather quickly.

SGI's XFS is 8 years proven on Irix, and has always been 64-bit.  The
Linux version is a _direct_ port, 100% structure-wise.  According to a
Linux Gazette article several years back, XFS offers the most features
as far as "data packing" and "offset/indexing" are concerned, as well as
maximum file and filesystem sizes.  Again, we're back to the design
focus, GB sizes and TB filesystems for video and large data (and it's
capable of PB, or petabyte as in 1 million terabyte, sizes).  XFS also
offers on-the-fly journal/fsck recovery (i.e. the filesystem is mounted,
then flushed and checked real-time), although the filesystem won't mount
when it needs an off-line "repair"** (which I've run into a couple of
times after a crash).

Best of all, despite all its "advanced features," XFS is _still_ a
"traditional" filesystem design.  That means it worked with NFS
off-the-bat and was the _only_ journaling filesystem with _official_
Linux quota support for the longest time (not even Ext3 for awhile). 
SGI also made sure _all_ XFS features were ported, including _full_
POSIX ACL support, as well as their "xfsdump" utility that preserved
them in backups (NOTE:  RedHat 8.0 ships star which does both Ext3 and
XFS ACLs now).  And now that Linus standardized POSIX EA/ACL support in
2.5.3, the SGI team has moved to support the same ACL interfaces
designed for Ext3, and have done so even on 2.4 in their forthcoming 1.2
release.

ReiserFS is from the Namesys group who believes filesystems should be
redesigned every 5 years.  ReiserFS v4 is now a true 64-bit design that
has a been given a DARPA research grant.  The ReiserFS design itself is
the most innovative approach, rather than the "evolutionary" ones of
other JFSes.  At the core is a database-like design that makes directory
and indexing extremely fast, resulting in a non-traditional inode
design.  Although this, among other things, resulted in NFS support
issues, even after Linus added it in stock 2.4.1+, most of those issues
have been worked out in newer kernels with patches.

Despite its age, ReiserFS _does_ have good journal recovery logic.  It
does a good job to fix any integrity automatically, and isn't shy to
force you to run a repair** manually.  And that's when you run into
issues.  Even though Linus required ReiserFS to "standardized" on a
"fixed format" before he included ReiserFS v3 in the kernel, it still
changes enough that sysadmins need to be "pro-active" in making sure
their utilities are "in-sync" with the release.  As such, I've seen
people _toast_ their ReiserFS filesystems with a manual repair when
required, because certain distro flavors** are not very "pro-active" in
making sure the correct utilities ship with the correct kernel with
ReiserFS.

Lastly, I have no idea what IBM is trying to do with JFS, because it
ported it from OS/2 instead of its AIX UNIX flavor -- which would have
been more appropriate.  IBM tends to do that to "avoid competition." 
The result is that I never looked at JFS because of its NFS, quota and
other incompatibilities when it was first released.  I don't know if IBM
has addressed them either.  Feature-wise the AIX version of JFS is
almost as good as XFS, but Linux didn't get that version.

And I have a further bias against JFS.  As a long-time admin of OS/2
(1989-1996) and NT (1992-present, yes before 3.1 was even released, long
story), I _hate_ both HPFS and NTFS.  Why?  Because they _always_ go to
their journals to avoid a CHKDSK.  The result is that I've had one HPFS
and two NTFS _production_ volumes self-toast themselves.  Downtime? 
Several days.  I've heard (which means this could be heresy) that JFS
from OS/2 (don't know about AIX) still practices that "aggressive
journal recovery" logic that doesn't agree with me.  I've known at least
two people who saw their JFS filesystems self-corrupt due to recovery of
an incomplete journal.

[ ** NOTE:  I've seen people running Mandrake with both XFS and ReiserFS
toast their filesystems with the repair utilities because they weren't
current, and/or the kernel patching was incompletely done.  Mandrake
might have the best installer and good looking utilities as well the
latest versions of programs, but their QA testing is virtually
non-existent, largely because they just "build and ship."  People bitch
about RedHat's "lag" on kernels and features, but damn them if they
don't test their kernels 2+ months in-house in production file server
roles.  It's also why RedHat only supports Ext3.  Although they ship
ReiserFS code and utilities ship, their policy on non-support is because
they don't want to deal with all the matching of kernel code and
user-space utilities (which _is_ a pain with ReiserFS).

Same deal with SGI and their XFS releases -- the code is usually in CVS
for 2-3 months before release for "regression testing" before release. 
And XFS has only has 1 major problem (in 1.0, which was fixed with 1.1)
since release on Linux.  Also note that SGI _only_ officially supports
it on RedHat and _no_other_ distro.  On the XFS list I've regularly seen
people have issues with non-RedHat versions from vendors who "sloppily"
patch their kernels with XFS rather non-completely. ]


-- 
Bryan J. Smith, E.I. (BSECE)       Contact Info:  http://thebs.org
[ http://thebs.org/files/resume/BryanJonSmith_certifications.pdf ]
------------------------------------------------------------------
* A lecture on software piracy from Bill Gates is like a lecture *
* on adultry from the owner of a brothel of other people's wives *

signature.asc
Description: This is a digitally signed message part