[systemd-devel] systemd-fsck-root semantics

[Chris Murphy]

On Jul 3, 2014, at 12:43 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Thu, 2014-07-03 at 12:00 -0600, Chris Murphy wrote:
>> What about a new fs_passno value of -1 that means "use default for this file system type", and systemd spawns fsck based on the recommendation of that file system's devs?
> 
> How should the file system devs communicate their current
> recommendation? If your answer is "they tell systemd developers, who set
> that in systemd source, and then systemd is shipped to users", that
> seems less than optimal.

Why? It's static. I don't expect the recommendations to ever change, let alone often.

> The "don't ship fsck.foo" or "symlink fsck.foo
> to /bin/true" methods seem much better from the point of view that the
> default is communicated with the filesystem tools.

OK, then this sounds like the switch is the existence of fsck.<foo>, not the value of the root entry's fs_passno, in which case fs_passno for / is being deprecated by systemd. That's not going to be obvious to anyone.

For many years now the fsck.<foo> is also a flag for a missing device. Hence upstream xfs-progs provides fsck.xfs, and Btrfs devs just added fsck.btrfs, for this purpose.

So you're suggesting either a.) distros need to remove fsck.<foo> if they use systemd; or b.) upstream fs projects need to stop shipping fsck.<foo> and distros need to add them if they don't use systemd and still need an fsck to check for missing devices.

What will actually happen in practice is fsck.<foo> will continue to exist, and will be a no op for those filesystems that don't do fsck. Which is what happens now.

Chris Murphy