On 03/01/13 19:50, Lennart Poettering wrote:
On Wed, 02.01.13 12:44, John Lane (syst...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
