[systemd-devel] no fsck at boot

[Chris Murphy]

On Jun 23, 2014, at 8:42 AM, Lennart Poettering <lennart at poettering.net> wrote:

> On Tue, 10.06.14 12:41, Chris Murphy (lists at colorremedies.com) wrote:
> 
>> 
>> 
>> 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.
> 
> systemd does not interpet any of these values. We just invoke fsck, and
> fsck then dispatches to the right binary for the specific fs, and that
> then interprets everything and does its fs-specific fsck magic.

OK that's fine. Maybe someone else can answer the question if fsck or fsck.ext4 automatically uses -f when the kernel detects either max-mount-counts or interval-between-checks. As originally reported, I'm not seeing "no fsck at boot" behavior, I'm seeing the opposite: it always is attempted.

> 
>> 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
> 
> Yes this is a known problem. We should fix it, but it's not obvious to
> fix, since this fsck is actually run by the initrd, not the host
> system. There's currently no nice way to pass information about whether
> fsck for the rootfs is requested to the initrd via kernel cmdline params
> (there's only the global fsck.mode=, but that applies to all mounts, not
> just the root fs). And I do wonder if it really is desirable even hav
> this, after all we want to stay generic, and carry as little information
> possible into the initrd.

For sure the fstab in my Rawhide initramfs contains nothing, it's empty. Therefore I'm assuming systemd could have no way of knowing what fs_passno is for root, until after root is ro mounted.

> I mean, I can totally see why fsck is
> something one might want to disable for debug reasons, but otherwise?

XFS and Btrfs make any repairs that can automatically be made at mount time. If mount fails, repairs aren't intended to be done unattended.  Also, fsck.xfs and fsck.btrfs don't actually do a file system check anyway, let alone repair. (For btrfs it comes with risks presently, and is next to a last ditch effort, ideally under advisement by a Btrfs developer.)

Ext3/4, a journal replay seems to fix quite a bit of problems too, without need for fsck. But ext3/4 has max-mount-counts and interval-between-checks, so it needs periodic fsck -f even if the journal replay comes up clean, so for that reason alone it needs an fsck in the initramfs. I don't know if the fsck -p (preen) on every boot is really necessary anymore or if the journal replay is adequate. That's maybe a valid question for an ext4 developer if this behavior is now kinda archaic or still applicable.

But in any case, is there a better way to trigger fsck for ext3/4, and not for XFS and Btrfs, based on some information other than fstab fs_passno? If systemd knew the root file system type before mounting, it could always issue fsck for ext3/4 and never do it for XFS and Btrfs. Maybe it's fs_passno that's become antiquated? Although this may not be generic enough so early in the boot process for systemd to determine file system type without a mount attempt?

> Anyway, that's the background story why we haven't done much about this
> bug so far…

Yeah it's a bit noisy in the journal and may cause some user confusion, but the sun still comes up in the morning.

Chris Murphy