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. >> 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. -- Thanks, Feri. ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users