[NTLUG:Discuss] Re: New Computer -- Ext3 and ReiserFS (go with the distro's support)

[Bryan J. Smith]

On Mon, 2004-11-15 at 02:50, Kevin Brannen wrote:
> I've had several Ext2 FS get so corrupt, we might as well call them 
> lost.  They generally got that way because of power loss, IIRC.  Yeh I 
> know, that's the worst thing you can do to a FS, but that's life sometimes.

I've never dropped an Ext2 filesystem, not even with physical disk
errors (or me stupidly not making sure my RAID driver and firmware were
compatible -- doh).  I've always been able to recover it.

> I've lost 1 Ext3 FS, not hurting and get most of the files back off, but 
> totally lost and useless dead.

I've always been able to recover Ext3 for the same reasons as Ext2.  The
full off-line fsck is just reliable.  Now you have to be careful to make
sure you have a compatible e2fsprogs package, but that's typically not
too difficult -- especially since 2.4.15+ (when Ext3 when into the stock
kernel).  I also stuck with Red Hat (or previously VA Linux)
kernels/releases.

> I don't remember the circumstances, but that put me off Ext3.

Hmmm, I've been running with Ext3 since the kernel 2.2.x patches.  Major
engineering setups -- back then it was hundreds of GBs.  Today I've
deployed TBs.

> I've had very good luck with Reiser, but then I've generally used Suse 
> systems, so I view that as Reiser done right.

Exactly.  As I've stated before, only SuSE seems to "do their homework"
with ReiserFS.  They were also the ones that told me I didn't want to be
using ReiserFS for my servers back in the late 2.2, early 2.4 days.  Now
that's technical honesty!

> Most Reiser horror stories I hear were on RedHat systems.

Mine were all Mandrake.  Largely the kernel implementation and off-line
packages not matching.  But in a couple of cases, even with SuSE's
packages that were "current," the RieserFS off-line utilities just don't
seem to get tested because the structure sometimes changes in the
kernel.

Otherwise, as long as the ReiserFS kernel implementation recovers the
journal, I've had 0 issues.  It's when it doesn't that I shake.  Just
doesn't compare to the proven e2fsck.

> Following the money of who supports who, that tells me Reiser is good on
> Suse, and use Ext3 on RH.  :-)

Exactly.  Stick with what the distro supports, and a distro that
supports it well.

I used to actively follow the SGI XFS list back in 2001-2002 and post
after post was people having problems on Mandrake.  And basically the
developers put down the hammer on "Mandrake doesn't do X, Y and Z" with
their codebase -- they just patched it in without much research and
pray.

> FWIW, I have seen a Reiser FS cook itself, but after much testing 
> plus wailing & gnashing of teeth, Chris Cox and I have decided that its 
> not Reiser's fault, but the hardware (an ill-begotten piece of garbage 
> manufactured by Compaq, their other models may be OK, but the n610c is 
> one to stay away from!).

As I've stated before, I've had some really nasty hardware screw-ups and
been _always_ able to recover an Ext2/Ext3 filesystem.  I might lose a
lot of various files in such cases, but I've never had a situation where
the filesystem couldn't be put back in a consistent state.

Now I have _heard_ of people using Ext3 in "writeback (meta)" mode for
performance drop the filesystems plenty of times.  That's why I stick
with either "journaled (full)" or "ordered (meta)."  I don't care about
performance, but reliability.

> YMMV and all that... :-)

Well, I haven't checked out XFS since the official releases for Red Hat
Linux 7.3.  Now that it's in the stock 2.6 kernel, I need to again.

Only a couple times did I have a XFS filesystem toast /var (and only
/var), and it was the well-known 1.0 issue that was fixed in 1.1.  XFS,
like Ext2/3, has been the same structure since the mid-'90s.  To me,
that makes off-line utilities the most trusted.  Because the raw
organization of the filesystem itself hasn't changed.

The ReiserFS team might swear by their attention to making sure kernel
implementations update structural changes, and I'll even believe them. 
But that doesn't help me when the journal replay fails, and it tells me
I need to run the off-line tools.  That's when I go "uh, oh."

-- 
Bryan J. Smith                                    b.j.smith at ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.