On Wed, 02.01.13 15:25, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Wed, Jan 02, 2013 at 12:44:10PM +0000, John Lane wrote: > > On 02/01/13 12:15, Andrey Borzenkov wrote: > > >В Wed, 02 Jan 2013 12:01:41 +0000 > > >John Lane <syst...@jelmail.com> пишет: > > > > > >>Hello, > > >> > > >>I have a configuration where a filesystem is mounted on /images. > > >> > > >>Then a subdirectory of that filesystem, say /images/1, is bind mounted > > >>on top as /images. > > > > 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) ? > Hi, > > it's on the TODO list ("* properly handle .mount unit state tracking > when two mount points are stacked one on top of another on the exact > same mount point.") Patches welcome :) This is actually about something different. I don't think we really should support stackable .mount units. However, we should handle it properly if somebody does that with external tools, and if then the mount unit is stopped we should unmount all mounts on the same mount point. This TODO list item is hence mostly about looping around /bin/umount when we stop a mount unit, rather than actually allowing multiple parallel mount units for the same mount path... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel