On Fri, 07 May 2004 11:17:16 -0500 Randy Kelsoe <randykel@xxxxxxxxxx> 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@xxxxxxxxxxx)
