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

[Lennart Poettering]

On Mon, 30.06.14 00:10, 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. 

Well, whether they install a symlink or whether they ship nothing at
all, both is fine. They just shouldn't install a tool that prints a
warning.

> 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.

Just because we had to add an awful hack to deal with the networking
mess (where I really don't know a better alternative), doesn't mean we
have to add one more here.

The nicer option appears to me is to talk to xfs and btrfs upstream and
ask them to either change their fsck to a symlink to /bin/true or to
remove it altogether. Because otherwise we cannot detect whether fscking
is actually necessary. I'd just reassign all bug reports popping up to
their respective utilities asking them to fix this, and giving us a
sane API to detct wether fsck is necessary or not. And that sane API
should be to to install that symlink or nothing at all.

> > 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 ;)

Wel, out of a matter of principle, I'd always try to fix things upstream
and properly where the problems lie, instead of taping over them. In
particular since btrfs upstream so far has always been nice to us...

Lennart

-- 
Lennart Poettering, Red Hat