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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 01, 2013 at 10:57:17AM +0200, Thomas Bächler wrote:
> Am 01.10.2013 05:10, schrieb Lennart Poettering:
> >>>> b) is tempting. Given fsck's improved internal ordering handling, is
> >>>> there actually a usecase for ordering the fsck's? I can't think of any
> >>>> off the top of my head...
> >>>
> >>> I struggle coming up with one. I mean, the only I could think of is "oh
> >>> my, it always used to work that way, and it is documented that way, you
> >>> break UNIX!", which isn't even a usecase, but just confusion.
> 
> Those were exactly my thoughts. And since systemd never had a problem
> with breaking tradition if it was a good idea, I thought we could simply
> go ahead.
> 
> 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. I think that since you're defining completly
new behaviour, it would be nice to implement this smartly, to avoid
constraining parallelization artificially.

> If file system checks actually need to be manually ordered in a certain
> manner  (which I would consider an edge case), systemd provides a much
> saner interface than a "pass number", namely Before= and After= ordering
> on the fsck services using .d files.
I'm not sure if it is saner. It is more verbose and complicated,
and most people like to configure their fsck's through /etc/fstab, since
it is more convinient than .d directories.

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.

> >> Things like that should probably just be automatically determined by
> >> the machine, and not requiring a human to invent weird passes to do
> >> the job. A boolean sounds fine to me.
> 
> As Kay mentioned, /sbin/fsck is rather powerful these days.
+1, as long as we don't break more complicated setups.

> > OK, sounds good to me. Anyone wants to cook up a patch that removes
> > FsckPassNo= from the core and makes sure the fstab generator only takes
> > the "passno" field in fstab as boolean to enable fsck or not?
> 
> My patch 1/3 already treats passno as a boolean - if passno > 0, we
> enable fsck, otherwise we don't. (passno < 0 is treated the same as
> passno == 0 by the current FsckPassNo code, so I kept that.)
> 
> I can cook up a patch that removes FsckPassNo= - I omitted it here since
> I was unsure whether people have it in unit files they wrote manually.

Zbyszek