Bug 1029455

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