[systemd-devel] no fsck at boot

[Chris Murphy]

On Jun 9, 2014, at 5:24 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:

> 'Twas brillig, and Reindl Harald at 09/06/14 19:57 did gyre and gimble:
>> what disturbs me is they warning about "touch /forcefsck" while
>> it's currently the *only* option to trigger a recommended fsck
>> at boot on a remote-server (and no add kernel params for that
>> in the grub-config and remove them after is not a sane way for
>> sysadmins maintaining 10,20,30 remote servers)
> 
> As has been mentioned numerous times, these warnings are there because
> if you need to use something to force an fsck (this current problem not
> withstanding) then modifying the suspect filesystem in question is a
> really bad idea! The warnings are in place to cover this use case and to
> discourage it as a first port of call without giving it proper thought.

On a Rawhide, systemd 212-4 system, using ext4, I get this at boot time when max-mount-counts as set with tune2fs -c is reached:

systemd-fsck[241]: /dev/sda3 has been mounted 3 times without being checked, check forced.

I can't actually tell if e2fsck -f was used, but that's what I'd expect, whereas the usual fsck used every boot with fs_passno 1 or 2 is e2fsck -p.

If I'm reading the thread correctly, a distinction by systemd is being made between max-mount-counts and interval-between-checks. It does the forced fsck for max-mount-counts, but not for interval-between-checks resulting in the need for /forcefsck being used. Regardless of whether systemd should just do the forced fsck or not, the behavior should be the same for both max-mount-counts and interval-between-checks.

Also on Rawhide, I'm finding that even if fs_passno is set to 0 , systemd is still doing fsck for root. Maybe it's arguably correct to ignore fs_passno 0 for root on ext234, but it's incorrect behavior for XFS and Btrfs and a bad hack for systemd to depend on a faux fsck.<fs> to ensure nothing is done even when nothing was asked to be done.
https://bugzilla.redhat.com/show_bug.cgi?id=1098799


Chris Murphy