[systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git

[Gustavo Sverzut Barbieri]

On Wed, May 23, 2012 at 8:51 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

Sure, I previously assumed that the systemd would be notified somehow
about the unit, but he explained that the generators run before
systemd actually check for units. Will try to remember this for the
next time ;-)


>> 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
> generator.
>
> 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.

In this case I'm still more for having the fstab parser bultin,
however I understand your point.

In my usage I'll just drop fstab and see what happens. For sure simple
"mount /mountpoint" will not work anymore, then I wonder if there is
any plan to provide systemd-mount to be linked as /bin/mount in order
to get the mount description (device, point, options) from systemd
mount units instead of fstab.


> They come at a price but that
> doesn't mean you should avoid them at all cost.

Agreed. The best part is that in this case we can avoid the extra pid
easily, systemd rocks :-)

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202