[KLUG Members] Laptop reiser corruption and fixing it

[Bryan J. Smith]

On Fri, 2002-01-25 at 10:40, Jamie McCarthy wrote:
> That was spurious;  it just turns out filesystem corruption is not
> handled well, at least not by reiser, and basically I was getting a
> kernel panic in a really bizarre way.  I think.  I'm not sure
> whether things would have been better or worse under a different
> filesystem than reiser.  But I'm tempted now to try ext3 at my
> earliest convenience.

I've tried to stay out of the "JFS wars," but there are 2 reasons why I
don't run ReiserFS myself:

1.  Non-standard inode layout can cause NFS service issues (at least to
non-Linux clients)

I run largely UNIX networks, usually with non-Linux NFS clients, so I
prefer a "traditional inode filesystem."  There are several patches so
kNFSd works perfectly with ReiserFS (according to many) under 2.4.x, but
I haven't tried them myself (nor do I wish to).  If you don't use
ReiserFS on your NFS servers, then this is a non-issue (and it probably
isn't an issue with Linux 2.4.x NFS clients either).

2.  I have regularly had several colleagues lose ReiserFS partitions,
especially after running the repair utilities.

This is most disturbing.  In most cases, ReiserFS continues to work for
most, with a "warning" about not having a completely integrity checked
system.  But in almost _every_case_ I have heard, running "repair" has
_toasted_ the filesystem, or caused _severe_data_loss_.  I don't know if
it is users not having their ReiserFS kernel/utilities out of sync, or
if the ReiserFS team is putting more focus on features and enhancements
instead of the repair utilities.

- WHY I'M BIASED TOWARDS EXT3

#2 is why I like Ext3, which I have been using since early 2000. 
ReiserFS _may_ have solid repair utilities, and I'm only hearing the
"bad."  But Ext3 uses the same, proven Ext2 fsck -- to the point where I
have had _physical_disk_trama_ and the fsck was able to recover the
filesystem (losing ~100 files in the affected areas, but it worked!)! 
So when you need to repair it with a full filesystem integrity check,
you get that 7 years of proven Ext2.  There is just no equal IMHO.  Ext3
also isn't "shy" about forcing you to do a full fsck.  If it sees
something it doesn't like in the journal read (after an improper
shutdown), it'll say "full fsck required" and drop you into single user
mode at boot.

Ext3 is in the official, stock kernel as of 2.4.15.  VALinux used it in
numerous products back in the older 2.2.x kernel series (and I used
their kernels with it on production servers).

- SGI'S XFS, THE JFS THAT GETS "NO RESPECT"

I have also been using SGI's XFS since February of 2001 on about a dozen
systems.  The main reason I did this is because it has official quota
support, as well as POSIX-compliant access control list (ACL) support --
which made it the most advanced, but traditional JFS available at that
time (although Ext2/3 now has both as well).  I have _never_ had to run
a manual repair on an XFS volume, although that doesn't mean I haven't
had any errors (I just don't know about them if I have).  In addition to
journaling, XFS does on-the-fly  repair/fsck -- which is extremely nice,
and has worked fine for me (I know there is work to add this to Ext3, I
think ReiserFS 4 has it too).  As long as your XFS kernel/utilities
match, I haven't seen anyone have any issues (although I've seen a few
people who haven't had them synced lose a lot of data or even a few
volumes!).  XFS does include a full, manual, off-line repair utility,
although I've never need to run it yet.

XFS is officially supported in the 2.5.x kernel.  Various XFS approaches
to filesystems support are being used as a basis for the 2.5.x kernel's
virtual filesystem (VFS) design, so all filesystems benefit.  SGI also
releases installer CDs for RedHat 7.x releases based on the same tested
and patched RedHat kernel RPMs (if you're a RedHat bigot like myself).

- WHAT I KNOW OF IBM'S JFS (ALL 3RD PERSON HERESY ;-):

I haven't used IBM's JFS, and I don't think I want to either.  It has
various support issues (NFS, quota, etc...) that have kept me from
trying it.  Furthermore, it seems to continue to tradition of, what I
like to call, "aggressive journal recovery" (AJR) just like HPFS (which
NTFS inherited from HPFS as well).  What I mean by AJR is that it
_always_ goes to the journal, and tries to _Avoid_ an fsck (or CHKDSK in
the case of HPFS/NTFS).  I have had two NTFS filesystems _toast_
_themselves_ on a journal read at boot, and I've heard of this happening
under JFS as well.  With NTFS, I always found myself _forcing_ a full
CHKDSK after improper shutdown, which defeats the purpose of journaling
anyway.  From what I've heard, JFS has the same issue.

-- Bryan

-- 
Bryan J. Smith, Engineer        mailto:b.j.smith@ieee.org
AbsoluteValue Systems, Inc.     http://www.linux-wlan.org
SmithConcepts, Inc.          http://www.SmithConcepts.com
---------------------------------------------------------
1999 IRS Data:  The top 1% of income earners pay over 36%
of the taxes, but have less than 20% of the total income.