RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1029455 - fsck.xfs refers to deprecated xfs_check
Summary: fsck.xfs refers to deprecated xfs_check
Keywords:
Status: CLOSED DUPLICATE of bug 1015632
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xfsprogs
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: Filesystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-12 12:27 UTC by Karel Volný
Modified: 2013-11-28 12:33 UTC (History)
1 user (show)

Fixed In Version: xfsprogs-3.2.0-0.3.alpha2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-26 17:02:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Karel Volný 2013-11-12 12:27:33 UTC 
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.
...
Comment 2 Eric Sandeen 2013-11-12 16:21:42 UTC 
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
Comment 3 Eric Sandeen 2013-11-12 17:15:57 UTC 
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.
Comment 4 Karel Volný 2013-11-19 12:55:04 UTC 
(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?
Comment 5 Eric Sandeen 2013-11-20 18:28:22 UTC 
(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
Comment 6 Karel Volný 2013-11-26 13:53:08 UTC 
(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
Comment 7 Eric Sandeen 2013-11-26 17:02:48 UTC 
Fixed as part of the 3.2.0-alpha2 update

*** This bug has been marked as a duplicate of bug 1015632 ***
Comment 8 Eric Sandeen 2013-11-26 17:10:25 UTC 
(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.
Comment 9 Karel Volný 2013-11-28 12:33:17 UTC 
(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
Note You need to log in before you can comment on or make changes to this bug.