Re: Inconsistent consistency checkers

[Andreas Dilger <adilger@sun.com>]

On Jun 30, 2009  10:16 -0400, Bob Peterson wrote:
> The rc.sysinit script used on many distros calls fsck specifying
> the "-a" option for the root file system and file systems specified
> to be checked in fstab.  According to the fsck man page, -a is to
> "Automatically repair the file system without any questions".  This
> -a parameter is passed on to the appropriate fsck.XXXX program.
> The problem is, the various fsck programs are inconsistent in how
> they interpret the -a parameter.  Here's a sampling (in alphabetical
> order):
> 
> btrfsck       - Rejects -a and -p (no ancillary command line args).
> fsck.ext2     - Accepts -a but translates it into -p.  Use of -a
>                 is discouraged.  The man page says "It is provided
>                 for backwards compatibility only; it  is  suggested
>                 that people use -p option whenever possible."

I don't quite understand why Ted made "-a" discouraged, but "-p" does
virtually the same thing.  I guess the theory is that "-p" doesn't
fix _everything_, and in some cases "-p" fails and requires manual
intervention.

> fsck.ext3     - Same as ext2
> fsck.ext4     - Same as ext3
> fsck.gfs2     - Rejects both -a and -p.
> fsck.hfs      - Rejects -a, but accepts -p.
> fsck.jfs      - Accepts -a and -p.
> fsck.minix    - Accepts -a but rejects -p.
> fsck.ocfs2    - Rejects both -a and -p.
> fsck.reiserfs - Accepts -a and -p.
> fsck.vfat     - Accepts -a but rejects -p.
> fsck.xfs      - Is completely a no-op with a good return code, the
>                 theory being that its journal recovery should make
>                 the fs sane.  If you REALLY want to check or repair
>                 your xfs file system, you need to run xfs_check or
>                 xfs_repair.

IMHO any fsck.* should at least do a minimal check of the filesystem,
as fsck.ext* does without "-f" (superblock, basic filesystem structures,
an on-disk error flag, in a second or two) so that the filesystem isn't
auto-mounted on reboot with serious corruption and possibly causing worse
corruption.  This is doubly true with any filesystem that has the
equivalent of "errors=panic" functionality, because it will otherwise
cause a cycle of mount-error-panic-reboot-mount-... until someone arrives
in the morning to find out what is broken.

Also, without either an on-boot check, or online repair (btrfsck?) it
isn't easy to check root filesystems, and lots of systems only configure
a single root filesystem these days.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.