Hide Forgot
Description of problem: Trying to check/repair a RHEL7 root filesystem, fsck reports an error instead of executing filesystem check. Version-Release number of selected component (if applicable): util-linux-2.23.2-6.el7.x86_64 How reproducible: always Steps to Reproduce: 1. boot in emergency mode 2. fsck /dev/mapper/rhel-root Actual results: fsck z util-linux 2.23.2 If you wish to check the consistency of an XFS filesystem or repair a damaged filesystem, see xfs_check(8) and xfs_repair(8). Expected results: if fsck.* acts as a wrapper for individual systems, I believe this logic should either be kept and act also for XFS, or either fsck.xfs be dropped if it can't work so, the above call should translate to xfs_repair /dev/mapper/rhel-root if the filesystem is mounted rw, and xfs_repair -d /dev/mapper/rhel-root if the filesystem is mounted ro (xfs_repair refuses to act on _any_ mounted filesystem, which is incosistent with other tools that are able to repair systems mounted read-only, hence this hack) Additional info: in any case, xfs_check should NOT be referred: # xfs_check xfs_check is deprecated and scheduled for removal in June 2014. Please use xfs_repair -n <dev> instead. ...
We can/should certainly remove xfs_check() from the output. But fsck.xfs has _always_ been a no-op. Using xfs_repair (-n / -d) is the correct thing to do. So what else would you like fixed besides removing the reference to now-deprecated xfs_check? -Eric
I've sent 3 patches upstream: 1) Remove reference to xfs_check in fsck.xfs output & manpage 2) Suggest "-d" if a repair is attempted of an RO mount (RFC patch) 3) Suggest immediate reboot when a "-d" repair is complete.
(In reply to Eric Sandeen from comment #2) > But fsck.xfs has _always_ been a no-op. are there any docs why? I hate inconsistent behaviour :-) (In reply to Eric Sandeen from comment #3) > I've sent 3 patches upstream: > > 1) Remove reference to xfs_check in fsck.xfs output & manpage > 2) Suggest "-d" if a repair is attempted of an RO mount (RFC patch) > 3) Suggest immediate reboot when a "-d" repair is complete. thanks; is there any upstream tracker to link here?
(In reply to Karel Volný from comment #4) > (In reply to Eric Sandeen from comment #2) > > But fsck.xfs has _always_ been a no-op. > > are there any docs why? yes: fsck.xfs(8) fsck.xfs(8) NAME fsck.xfs - do nothing, successfully SYNOPSIS fsck.xfs [ filesys ... ] DESCRIPTION fsck.xfs is called by the generic Linux fsck(8) program at startup to check and repair an XFS filesystem. XFS is a journaling filesystem and performs recovery at mount(8) time if necessary, so fsck.xfs simply exits with a zero exit status. > > I've sent 3 patches upstream: > > > > 1) Remove reference to xfs_check in fsck.xfs output & manpage http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commitdiff;h=12a48f5d8a06a8ca21b6221e94318e4922f0316c > > 2) Suggest "-d" if a repair is attempted of an RO mount (RFC patch) > > 3) Suggest immediate reboot when a "-d" repair is complete. These last two aren't merged yet but will be soon, I hope. -Eric
(In reply to Eric Sandeen from comment #5) > fsck.xfs is called by the generic Linux fsck(8) program at startup to > check and repair an XFS filesystem. XFS is a journaling filesystem and > performs recovery at mount(8) time if necessary, so fsck.xfs simply > exits with a zero exit status. unfortunately, this doesn't make me any wiser ... XFS is not the only journalling filesystems, yet the others can be fscked if the key part is "at mount time", then a) I see it as a big design flaw not to be able to check (and repair) independently b) I still don't understand why it couldn't be possible do something like fake mount to force the mount-time check > > > I've sent 3 patches upstream: > > > > > > 1) Remove reference to xfs_check in fsck.xfs output & manpage > > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commitdiff; > h=12a48f5d8a06a8ca21b6221e94318e4922f0316c cool > > > 2) Suggest "-d" if a repair is attempted of an RO mount (RFC patch) > > > 3) Suggest immediate reboot when a "-d" repair is complete. > > These last two aren't merged yet but will be soon, I hope. ok, thanks
Fixed as part of the 3.2.0-alpha2 update *** This bug has been marked as a duplicate of bug 1015632 ***
(In reply to Karel Volný from comment #6) > unfortunately, this doesn't make me any wiser ... XFS is not the only > journalling filesystems, yet the others can be fscked > > if the key part is "at mount time", then > a) I see it as a big design flaw not to be able to check (and repair) > independently independently? I'm not sure what you mean. > b) I still don't understand why it couldn't be possible do something like > fake mount to force the mount-time check Different projects, different philosophies, different behaviors. There _is no need_ to force a fsck at mount time. If anything, it's ext3/4 with the odd behavior here. xfs *can* be repaired, it's just not done as an automatic step at reboot. Repair/fsck is exception activity, it should be carefully initiated by the administrator. I've removed xfs_check references (good catch there) but "run fsck at boot time just in case" simply won't be done for XFS.
(In reply to Eric Sandeen from comment #8) > (In reply to Karel Volný from comment #6) > > > unfortunately, this doesn't make me any wiser ... XFS is not the only > > journalling filesystems, yet the others can be fscked > > > > if the key part is "at mount time", then > > a) I see it as a big design flaw not to be able to check (and repair) > > independently > > independently? I'm not sure what you mean. "XFS ... performs recovery at mount(8) time" - why it can't perform it _without_ mount, why it cannot be triggered without calling mount? in the other bug I've reported (bz#1029527) I see xfs_repair tells me to do mount/unmount at first ... why xfs_repair cannot just do the same as mount would do, without actually mounting the filesystem? > > b) I still don't understand why it couldn't be possible do something like > > fake mount to force the mount-time check > > Different projects, different philosophies, different behaviors. it is nice to have a choice, but only up to some extent ... most sysadmins (to my best knowledge) prefer consistency - things can be different under the hood but being able to mimic behaviour of each other helps a lot I'm not calling for all cars being black, I just want the ability to paint the Ford pink to match my Cadillac > There _is no need_ to force a fsck at mount time. If anything, it's ext3/4 > with the odd behavior here. seems there's misunderstanding here - by "mount-time check" I mean the "recovery" thing or how is that called in XFS, not that it should happen at mount time > xfs *can* be repaired, it's just not done as an automatic step at reboot. > Repair/fsck is exception activity, it should be carefully initiated by the > administrator. there's difference between "repair" and "check" doing a check at boot time is IMHO a good idea; yes, the repair should happen under admin control (except for some trivialities) but even ext2/3/4 doesn't do a full repair at boot time without admin's presence > I've removed xfs_check references (good catch there) but "run fsck at boot > time just in case" simply won't be done for XFS. I just think that this should be resolved elsewhere because avoiding the check in fsck.xfs just breaks its consistency with other fsck.something tools