[systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
lennart at poettering.net
Wed May 23 04:51:39 PDT 2012
On Tue, 22.05.12 18:13, Gustavo Sverzut Barbieri (barbieri at profusion.mobi) wrote:
> On Tue, May 22, 2012 at 3:03 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > Heya,
> > just a quick heads-up. I just commited to git some work that rips out
> > the fstab parsing from PID 1 and places this in a generator instead. The
> > idea is that sooner or later we only parse native unit files from PID 1,
> > and everything else is transformed as needed with generators. This makes
> > the core a bit smaller and simplifies a lot of things.
> > This is quite a substantial change, and hence I am not sure I got it all
> > right. I am writing this mail for two reasons: to warn you that current
> > git might break your boot more likely then usually, and secondly: please
> > test this, especially if you have a more complex setup with nofail,
> > noauto and x-systemd.automount in the mix!
> Lennart, Kay: I hate you damn it! :-D
> Man, how can a fstab file be so complex to justify it? It's simpler
> than the service files we already load. Now to simply parse /etc/fstab
> we need to call a generator, that parses (was being done already),
> generates a new file, that triggers inotify, that calls systemd, that
> parses it again. Ouch, that's cumbersome at least, slow at last!
Well, as Kay is pointed out this paragraph makes little sense.
That said I can give you a number of reasons why it actually might be
faster this way:
- The generators are all executed in parallel, and hence allow a level
of parallelization we didn't have before
- fstab mount units are now subject to the same kind of lazy loading we
have for all other units hence otpimizing resource usages
- People who don't need fstab (embedded and containers) can leave the
generator out entirely and thus save time and resources
- if you feel like it you can even run the generator offline and use the
generator unit files for all next boots, to speed up things for
certain embedded use cases.
The summary of this is probably: without proper profiling claiming that
things slow down stuff is non-sense.
> One suggestion at IRC was to just keep systemd mount units. But if we
> should go this route, then we should call to deprecate /etc/fstab.
> Last time we discussed about it, people said it was not going to
> happen since some tools were parsing and relying on it. Whats is the
> way to go?
We don't really deprecate it. But if people want to they don't have to
use it now, and can do this easily by dropping the file and removing the
You know, fewer PIDs are definitely a good thing, but for some things
doing them out-of-process is actually a good thing. Unix knows processes
and process isolation for a reason. They come at a price but that
doesn't mean you should avoid them at all cost.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel