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

[John Lane]

On 03/01/13 19:50, Lennart Poettering wrote:
> 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.
Could we consider the units generated from /etc/fstab as a special and 
straightforward case, where the generator can base the unit dependencies 
on the ordering that the mount definitions are listed in /etc/fstab? 
Like you say "whatever comes first in fstab is mounted first". There may 
be other ways to configure mount units but we are only talking here 
about those generated from /etc/fstab.

if /etc/fstab is not going away then the possibility of arranging mounts 
in that file which break in systemd will remain.
>
> 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...
The patch I supplied attempts to address this also (unless there is more 
to it than what seemed to be the case when I looked at it).
>
> 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?

I didn't want to muddy the waters by discussing the pros and cons of my 
use-case but I'll explain in case it helps.

A custom configuration here allows a system to have multiple system 
images to help support upgrade and rollback: a 'live' one that is 
running and others that are not. Each has their own partitions except 
there needed to be a single /boot partition. Each system writes their 
own boot files to the same /boot partition but each has its own 
subdirectory on it. It is this subdirectory that is overmounted so the 
running system sees its own boot files at /boot where it expects them to 
be. It's been running like that smoothly for a very long time and has 
only become an issue with the transition to systemd.

I have updated my patch so it writes an "After=" dependency as per Tom's 
comment. It's here:

https://raw.github.com/johnlane/archlinux-systemd/master/fstab-overmount.patch

(I'll do a git-send-email tomorrow once I sort out smtp access for the 
box I was testing this on)

With that patch, I have systemd working well for the above use-case.

I'm going to leave it at that until there's more of a discussion by 
people more knowledgeable than me but, If I can help in any way, do let 
me know. I would obviously like to see this supported as I have a 
genuine use-case for over-mounting that I have been able to do for as 
long as I can remember.

Regards,
John

> Lennart
>