Bug 1278361 - Make fsck.xfs a link to /bin/true
Summary: Make fsck.xfs a link to /bin/true
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xfsprogs
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-05 10:36 UTC by Marcos Mello
Modified: 2015-11-07 21:29 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-06 17:57:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Marcos Mello 2015-11-05 10:36:28 UTC
This way systemd >= 215 will not unnecessarily run it:

https://github.com/systemd/systemd/commit/571d0134bd464444567cf4eb0d2ed8df40045f36

Btrfs folks recommends same setup for fsck.btrfs:

https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs

Comment 1 Marcos Mello 2015-11-05 10:46:46 UTC
Discussion on the matter:

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/20572

Comment 2 Eric Sandeen 2015-11-05 15:48:46 UTC
fsck.xfs is a no-op anyway, so why bother?

While I agree that hard-coding a skip into systemd is a very bad idea, I also see no advantage to changing the fsck.xfs that we have today.

What does it gain?

fsck.xfs also informs the hapless user that they're using the wrong tool, if they invoke it in non-auto mode:

# fsck.xfs /dev/sdb1
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).


so I see no compelling reason to change this to a symlink.  Can you convince me?

Comment 3 Eric Sandeen 2015-11-05 15:56:41 UTC
Also, I believe that fsck.xfs exists because on some systems, if an fs_passno is non-zero (or maybe even if it is zero?), a missing fsck.$FSTYPE will cause the system to fail boot.  I don't remember exactly, but in the back of my head that was the case, and was the original motivation for the helper script.

Comment 4 Eric Sandeen 2015-11-05 16:12:59 UTC
See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750673

Comment 5 Marcos Mello 2015-11-05 20:54:36 UTC
The gain is avoid pointless processes spawned at boot. But you raised the hapless user case, that is indeed valid. However I assume any competent admin would read a man page before interacting with the filesystem in use.

util-linux's fsck does not error out if fsck.xfs and fsck.btrfs are missing since version 2.25 and just returns 0:

https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c7a96884eb10997286233527fcd4dcaa64d72853

Debian does not use systemd in its initramfs. In Wheezy they did not even used systemd at all (by default).

There is a problem in dracut unfortunately. It transforms an absolute symlink into a relative one in the initramfs and breaks systemd-fsck logic. Probably an easy fix.

Not sure I can convince you. Anyway, fsck.xfs(8) and true(1) are *very* similar. :-)

Comment 6 Eric Sandeen 2015-11-05 21:07:22 UTC
Thanks for the util-linux commit link, that's good to know.

But also - why is fs_passno == 0 not sufficient to avoid the fsck call in the first place?  systemd can recognize a link to /bin/true but doesn't parse fstab for fs_passno?

"If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked."

(I understand that Debian does not use systemd in initramfs; this just points out that all the world is not systemd, so we can't cater exclusively to its needs & desires)

> However I assume any competent admin would read a man page before interacting with the filesystem in use.

You're funny!  ;)

Anyway, fsck.xfs does 2 things; it returns an error if the device doesn't exist at all, and does the warning about using the wrong tool, if it seems to have been invoked by an admin.  I'm not sure about the historic reasons for the device check, either, to be honest.

I can't imagine that the overhead of spawning a trivial & short shell script is all that critical, is it?  Unless there is some actual *problem* which needs fixing here, I'm inclined to leave things as they are.  But, this could also be brought up on the XFS list for further discussion, if you'd like.

Comment 7 Marcos Mello 2015-11-06 16:03:59 UTC
Hmm, yes, systemd is running fsck on my root filesystem in the intramfs with fs_passno 0. I will take a look at that.

Comment 8 Marcos Mello 2015-11-06 17:57:05 UTC
I got it. Dracut, only for root= and usr= cmdline filesystems, always assumes fs_passno 1, as it does not carry (at least by default) an fstab copy. After systemd switched to the root filesystem, fstab-generator will interpret /etc/fstab for the remaining ones.

In the end, you are right. Let's keep things as they are now. Sorry for the noise.

Comment 9 Marcos Mello 2015-11-07 21:29:47 UTC
(In reply to Marcos Mello from comment #8)
> I got it. Dracut, only for root= and usr= cmdline filesystems, always

The option is mount.usr= actually.


Note You need to log in before you can comment on or make changes to this bug.