[systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

[Lennart Poettering]

On Wed, 02.01.13 12:44, John Lane (systemd at jelmail.com) wrote:

> I realise I can work around the problem (that's what I am doing
> right now) but I want the mounts to be done in that way (one over
> the other).
> 
> As such an /etc/fstab worked fine before systemd it would be good if
> it continued to work with systemd.
> 
> I think the problem is how systemd names the generated mount units.
> If there is a clash, could it not
> use a modified name for the unit (e.g if
> /run/systemd/generator/images.mount exists it would create
> /run/systemd/generator/images-1.mount or something like that) ?

Humm, I am very conservative about this I must say.

In general we have the rule that the mount unit for a path is named
after the path (while replacing "/" by "-" and appending ".mount" to
it), and this is enforced in the code. Allowing multiple .mount units
for the same path would really complicate the whole system, and I am not
convinced that that would be worth it.

systemd automatically determines a multitude of dependencies between the
units. For example if a mount point lies beneath another mount point
they gain implicit ordering deps. Similar, if a socket unit refers to a
file system socket on a specific mount point they gain ordering deps
implicitly too, and so on. In fact, much of what is nice in systemd is
based on implicit dependencies.

Now, if you allow multiple separate mount units for the same path this
all becomes really complicated. Because how do you handle the ordering
deps for those? How do you handle the ordering deps *between* the two?
Sure you can say "whatever comes first in fstab is mounted first", but
that only gets you so far, as fstab is just one way to configure mount
units, and they can come from other sources too. Also, native units are
loaded only when referenced, in order to optimize the footprint of
systemd. That basically means the "first mention" rule becomes very much
chaotic, since whatever unit is referenced first wins, and that
recursively.

Also, I have my doubts that other software would be fine with these
clashes, either. I am pretty sure most folks would assume that mount
point names are unique, and this will be coded into many projects, not
just systemd.

Just changing the generator to output alternate .mount units if a clash
happens won't solve your issue btw, because the mount path will still
have to be in sync with the mount unit name. And since you cannot have
two files with the same name in a directory you can't have two units for
the same mount point either...

So, before we spend time on implementing this, we really should figure
out if this is a desirable feature, or if there are better ways to solve
this usecase. I guess the first question needs to be: what's the usecase
anyway? if we know that, maybe we can find a nicer way?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.