[KLUG Members] Laptop reiser corruption and fixing it

[Michael W. Holdeman]

Thanks for all the good info! I've been researching a FS for a newfile server 
I'm getting ready to set-up. I think the old EXT2 will probably win out.


Mike

On Saturday 26 January 2002 00:34, you wrote:
> 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