[systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck at .service instead of using FsckPassNo

[Thomas Bächler]

Am 01.10.2013 12:30, schrieb Zbigniew Jędrzejewski-Szmek:
>> Now, according to the fstab(5) manpage, the root fs should have passno 1
>> and everything else should have passno 2. We could ensure the same
>> behaviour by having After=systemd-root-fsck.service in
>> systemd-fsck at .service.
> Serializing fscks like that makes only limited sense if you're doing
> it from the initrd. But if the fsck is run from the ro root, then yes,
> I guess you want to make sure that the fs that holds the fsck binaries
> is OK before continuing.

That's why systemd-root-fsck.service should be ordered before all
systemd-fsck at .service units. This only affects the non-initrd case. In
the initrd case, systemd-root-fsck should not be run anyway and the
ordering I suggested has no effect.

> Manual ordering is a bit of a corner case, but like Jan Engelhart wrote...
>> On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs.
>> The iSCSI client will import them as /dev/sda and /dev/sdb.  That is a
>> case where, if you can, you would specify FsckPassNo because the
>> automatic detection likely stops at host boundaries.
> ...there might be use cases. Even if we drop support for ordering by
> fsck-no field in /etc/fstab, do we have a new way of configuring this
> through /etc/fstab? (Something like
> x-systemd.comment=After=systemd-fsck-var.service ?)
> Or is this really too much of an edge case? I don't think that the current
> fsck-no-related code is harmful in any way or a maintenance burden, so
> if it is dropped, it would be nice to cover all bases.

If we are to keep the strict fs_passno as documented in fstab(5), I
suggest we go with Lennart's suggestion:

> d) Pimp up fstab-generator to write only .d dropins that add the
>    necessary deps between the fsck instances, but nothing else.

I find the whole concept of the FsckPassNo option disturbing (including
its documentation). It introduces an additional directive for something
that can be solved with the existing ones, with the comment that it
should only be used for certain types of services, or not at all. An
option that shouldn't be used in newly written units shouldn't be used
in generated ones either.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131001/8c389a72/attachment-0001.pgp>