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. 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel