Inconsistent consistency checkers

Inconsistent consistency checkers

[Bob Peterson]

Hi linux-fsdevel,

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."
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.

(I'm going by the man pages for the most part here, so some of them
may accept -a or -p and just not have them documented.)

I'd like to see consistency in the various fscks regarding -a and -p,
especially in the light of how rc.sysinit specifies it.

If -a is the accepted "Do what repairs you can safely" then its use
should not be discouraged by the fsck.ext* man pages and all fscks
should accept the -a parameter and interpret it the same way.

If, on the other hand, -a is being phased out in favor of -p, then all
fscks should accept -p and rc.sysinit should be changed.

If the checkers should accept both -a and -p, then the fscks that
currently reject either should be changed and possibly map them to
whatever makes the most sense.

Opinions?  How do people feel about this?  Can we standardize?

Regards,

Bob Peterson
Red Hat File Systems

Re: Inconsistent consistency checkers

[Andreas Dilger]

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.