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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
