recommending reiserfs?

[John Thompson]

On Fri, 07 May 2004 11:17:16 -0500
Randy Kelsoe <randykel at swbell.net> wrote:

> John Thompson wrote:
> 
> >fsck.xfs exists only because linux automatically runs fsck against
> >all filesystems as part of the boot process. When fsck.xfs is run, it
> >simply returns a successful message back to fsck so the boot process
> >can continue.  When the boot process subsequently mounts the xfs
> >filesystem, xfs_check is run to determine if the filesystem is
> >"dirty" and then the journal is played back and/or xfs_repair will be
> >called to do the actual fixing.

> I could be wrong, but I understand that on boot, the filesystems are 
> checked for the 'dirty bit' being set. When the system is shutdown 
> cleanly, the 'dirty bit' is cleared. Once booted, the bit is set, so
> if the machine crashes without cleanly unmounting the filesystem, the
> bit will still be set. If the bit is not set, fsck is never run
> (unless an fsck is forced), and the machine is happy. If the bit is
> set, THEN fsck is called.

What do you think checks for the "dirty" bit?  That's right; "fsck." If
it find the dirty bit set, it calls the filesystem-appropriate utility
(eg "fsck.ext3" or whatever) to check and fix any problems.  When fsck
finds the dirty bit set on an xfs filesystem, it calls "fsck.xfs" which
simply returns a "successful" signal back to fsck, which then moves on
to the next filesystem.  When the xfs filesystem is eventually mounted and 
finds itself dirty, then xfs_check/xfs_restore are used to fix things up. 

I suspect this round-about way of doing things is a result of xfs' IRIX
history, which does things slightly differently than linux.  Creating a
dummy fsck.xfs utility allows xfs to be more easily integrated into the
linux scheme of things.

-- 

-John (john at os2.dhs.org)