On Wed, 2010-05-12 at 23:18 +0200, Daniel Lezcano wrote: > 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.
Are you SURE you want /usr/${libdir}/lxc for this? Some high security
systems might mount /usr as a separate read-only partition (OK - I'm and
old school old fart). Part of the standard allows for /usr to be an RO
file system.
Wouldn't this be more appropriate in /var/${libdir}/lxc instead? Maybe
create a .tmp directory under it or .tmp.${CTID} or something? Or,
maybe, something under /var/${libdir}/lxc/${CTID}/tmp instead? /var is
for things that change and vary. Wouldn't that be a better location and
you've already got control of the /var/${libdir}/lxc location, don't
you?
> >>> 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.
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
