[systemd-devel] [PATCH] fstab-generator: do not check btrfs and xfs

[Tom Gundersen]

On Mon, Jun 30, 2014 at 12:10 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote:
>> This sounds really unnecessary, no? We already have fsck_exists()  in
>> place that since a very recent commit of mine even detects a per-fstype
>> fsck implementation being linked to /bin/true... I also downgraded all
>> warnings for cases like that to LOG_DEBUG, hence the xfs/btrfs case
>> should already be covered nicely, and fully generic... Why do we need
>> another explicit blacklist on top of that?
> True. But this requires additional effort from the initramfs generator
> and from the distribution to remember to install the symlink. We already
> have a list of network filesystems, this just another one which is actually
> much easier to manager since new local filesystems with automatic repair
> don't come that often.
>
> Since btrfs and xfs recommend to use passno=0 in fstab, their decision
> to avoid fsck is pretty much baked in forever. If this was ever to change,
> patching systemd will be much easier than all the fstabs.
>
> Starting a unit which is very strongly ordered before all other units,
> just to start a binary to check whether the symlink is there, or nothing
> at all, when we know what the result will be anyway, seems pointless.
>
> On Sun, Jun 29, 2014 at 11:52:26PM +0200, Tom Gundersen wrote:
>> On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger <lists at xunil.at> wrote:
>> > Am 29.06.2014 23:24, schrieb Lennart Poettering:
>> >> On Sun, 29.06.14 21:51, Kai Krakow (hurikhan77 at gmail.com) wrote:
>> >>> # /sbin/fsck.btrfs /dev/sdb3
>> >>> If you wish to check the consistency of a BTRFS filesystem or
>> >>> repair a damaged filesystem, see btrfs(8) subcommand 'check'.
>> >>
>> >> Is this an upstream thing? Or is that specific to your distro?
>> >>
>> >> It sounds really wrong to me to do something like what they are
>> >> doing. Either they provide a real implementation, or they don't supply
>> >> an implementation. Either is fine. But if they supply an implementation
>> >> that justs prints a warning will simply mean that various tools
>> >> (including systemd) will invoke it, for no reason.
>> >
>> > This is how gentoo currently implements things.
>> > So the devs there should link it to /bin/true ?
>> > We could open a bug for that at bugs.gentoo.org ...
>>
>> IMHO both xfs and btrfs should just not ship a fsck helper at all, not
>> even as a symlink. This workaround made sense at some point, but now I
>> believe both systemd _and_ fsck itself can deal gracefully with a
>> missing fsck helper.
> IMHO, this shows that using fstab-generator to shortcuit the whole
> discussion who is right and what is the "proper" way to say that the fs
> should not be checked seems like a good idea ;)

Well, for use in fstab this is not really an issue (as there people
can just set the passno), so it only really makes a difference on the
kernel commandline. In that case I guess most people don't actually
specify the filesystem type anyway, and rely on the auto logic so the
patch won't help. My feeling is that this will not really solve the
problem, just add to the confusion :)

-t