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

[Lennart Poettering]

On Tue, 01.10.13 04:42, Kay Sievers (kay at vrfy.org) wrote:

> 
> On Tue, Oct 1, 2013 at 4:29 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Tue, 01.10.13 04:19, Tom Gundersen (teg at jklm.no) wrote:
> >
> >> > I'd love to get rid of FsckPassNo=, but I fear that's not that
> >> > easy... After all it's not just a boolean, it actually influences the
> >> > ordering of the fsck. There traditionally were two documented phases
> >> > which you could use to serialize multiple fsck on the same HDD
> >> > but different partitions, but parallelize it on different HDDs. Now,
> >> > fsck since a while can determine all that automatically these days. But
> >> > still by using FsckPassNo= you get ordering deps automatically added.
> >> >
> >> > a) leave everything as is and FsckPassNo= does odering deps
> >> >
> >> > b) declare that manual passno configuration is stupid beyond treating it
> >> >    as simple boolean. In thatc ase we should drop all references of
> >> >    passno in the sources. Of course people might complain that we break
> >> >    compat with UNIX, but well...
> >> >
> >> > c) Pimp up fstab-generator to write complete unit files for
> >> >    fsck at .service that include the right dependencies. Meh.
> >> >
> >> > d) Pimp up fstab-generator to write only .d dropins that add the
> >> >    necessary deps between the fsck instances, but nothing else.
> >> >
> >> > I think c) and a) suck. b) sounds like the best option to me. d) sounds
> >> > workable too.
> >> >
> >> > If we go for b) then I figure people might complain that fstab(5) is not
> >> > longer compatible with what systemd does?
> >>
> >> 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.
> >
> > I have the suspicion that if we remove support for it, and don't tell
> > anyone nobody might actually notice.
> >
> > So maybe we should just go ahead and change it to become a boolean only,
> > and not tell anyone, and that's it? Opinions?
> 
> 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.

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?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.