[systemd-devel] Inconsistencies in the systemd.mount documentation

[Lennart Poettering]

On Wed, 21.08.13 19:55, Thomas Bächler (thomas at archlinux.org) wrote:

> In the manpage for systemd.mount(5), the following section is included:
> 
> COMPATIBILITY OPTIONS
>        The following option is also available in the "[Mount]" section,
> but exists purely for compatibility reasons and should not be used in
> newly written mount files.
> 
>        FsckPassNo=
>            The pass number for the file system checking service for this
> mount. See systemd.service(5) for more information on this setting.
> 
> 
> However, if you omit the FsckPassNo= option from a mount unit, no
> dependency upon the correct systemd-fsck@ instance is created. So in
> fact, the option has a function.
> 
> I'm not sure if this is intended, but in my opinion,
> DefaultDependencies=yes in a .mount unit should create that dependency,
> not the presence of a compatibility options. Does anyone know more?

Hmm, when I wrote that my idea was that people would add the dep on the
fsck service instances themselves.

Using FsckPassNo= as a way to add that dep sucks really, because the
ordering it does is stupid and fsck can do the ordering internally
anyway these days...

Automatically adding deps to fsck for all mounts is wrong too, since
only some block-based file systems need fsck and it would suck having to
carry a whitelist for thos in systemd.

So dunno. I am still tempted to say that people should add the dep
manually if they want fsck, but this is something to document I guess...

(Note that this is a real problem already as the /boot mount the EFI
mount generator creates currently doesn't pull in fsck, but really
should...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.