Ferenc Wagner wrote: > Daniel Lezcano <daniel.lezc...@free.fr> writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano <daniel.lezc...@free.fr> writes: >>> >>> >>>> Ferenc Wagner wrote: >>>> >>>> >>>>> Actually, I'm not sure you can fully solve this. If rootfs is a >>>>> separate file system, this is only much ado about nothing. If rootfs >>>>> isn't a separate filesystem, you can't automatically find a good >>>>> place and also clean it up. >>>>> >>>> Maybe a single /tmp/lxc directory may be used as the mount points are >>>> private to the container. So it would be acceptable to have a single >>>> directory for N containers, no ? >>>> >>> Then why not /usr/lib/lxc/pivotdir or something like that? Such a >>> directory could belong to the lxc package and not clutter up /tmp. As >>> you pointed out, this directory would always be empty in the outer name >>> space, so a single one would suffice. Thus there would be no need >>> cleaning it up, either. >>> >> Agree. Shall we consider $(prefix)/var/run/lxc ? >> > > Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot > if /var/run is on tmpfs. This isn't variable data either, that's why I > recommended /usr above. > Good point. I will change that to /usr/$(libdir)/lxc and let the distro maintainer to choose a better place if he wants with the configure option.
>>> Now the question is: if rootfs is a separate file system (which >>> includes bind mounts), is the superfluous rbind of the original root >>> worth skipping, or should we just do it to avoid needing an extra >>> code path? >>> >> Good question. IMO, skipping the rbind is ok for this case but it may >> be interesting from a coding point of view to have a single place >> identified for the rootfs (especially for mounting an image). I will >> cook a patchset to fix the rootfs location and then we can look at >> removing the superfluous rbind. >> > > I'm testing your patchset now. So far it seems to work as advertised. > Cool, thanks for testing. ------------------------------------------------------------------------------ _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
