On Mon, Sep 14, 2015 at 07:27:06PM +0000, Serge Hallyn wrote:
> Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > On Mon, Sep 14, 2015 at 04:33:05PM +0000, Serge Hallyn wrote:
> > > Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > > > Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > > > > On Mon, Sep 14, 2015 at 02:50:39PM +0000, Serge Hallyn wrote:
> > > > > > Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > > > > > > When creating ephemeral containers that have the option
> > > > > > > lxc.ephemeral = 1 set
> > > > > > > in their config, they will be destroyed on shutdown. As they are
> > > > > > > simple overlay
> > > > > > > clones of an existing container they should be registered in the
> > > > > > > lxc_snapshots
> > > > > > > file of the original container to stay consistent and adhere to
> > > > > > > the
> > > > > > > expectancies of the users. Most of all, it ensure that we cannot
> > > > > > > remove a
> > > > > > > container that has clones, even if they are just ephemeral
> > > > > > > snapshot-clones. The
> > > > > > > function adds further consistency because
> > > > > > > remove_snapshots_entry() ensures that
> > > > > > > ephemeral clone-snapshots deregister themselves from the
> > > > > > > lxc_snapshots file
> > > > > > > when they are destroyed.
> > > > > > >
> > > > > > > POSSIBLE GLITCH:
> > > > > > > I was thinking hard about racing conditions and concurrent acces
> > > > > > > on the
> > > > > > > lxc_snapshots file when lxc-destroy is called on the container
> > > > > > > while we
> > > > > > > shutdown then container from inside. Here is what my thoughts are
> > > > > > > so far:
> > > > > > >
> > > > > > > There should be no racing condition when lxc-destroy including
> > > > > > > all snapshots is
> > > > > >
> > > > > > Note that lxcapi_destroy_with_snapshots() deletes the *snapshots*,
> > > > > > not the
> > > > > > snapshot clones. This is an unfortunate naming clash (which we
> > > > > > could try
> > > > > > to correct henceforth but we need good names :), but they are
> > > > > > different.
> > > > > > So anything under /var/lib/lxc/$container/snaps will be deleted.
> > > > > > But if
> > > > > > you've created an overlayfs clone, then containers listed in
> > > > > > /var/lib/lxc/$container/lxc_snapshots will not be deleted. There is
> > > > > > no
> > > > > > API call or program to automatically deleted those right now.
> > > > >
> > > > > I think you are partially wrong here. I was not thinking about
> > > > > problems created
> > > > > by an API-call but by the lxc-destroy exectuable. A quick
> > > > > walkthrough: With the
> > > >
> > > > D'oh. Yeah, you'll need to mutex that somehow.
> > >
> > > If you want help up-front with the design, please let me know. If you
> > > aren't sure what the current container_disk_lock() and
> > > container_mem_lock()
> > > do, please shout. (they are explained in a LOCKING comment above
> > > lxc_container_free() in src/lxc/lxccontainer.c)
> > >
> > > The easiest thing to do mght be to disk_lock the container in
> > > lxc_destroy.c,
> > > then make the mod_rdep() helper which you use in lxc_destroy.c be a
> > > _locked
> > > variant (to avoid deadlock). So mod_rdep() would turn into something
> > > like:
> > >
> > > static bool mod_rdep(struct lxc_container *c0, struct lxc_container *c,
> > > bool inc)
> > > {
> > > bool ret;
> > > if (container_disk_lock(c0))
> > > return false;
> > > ret = mod_rdep_locked(c0->name, c0->lxcpath, c->name, c->lxcpath);
> > > container_disk_unlock(c0);
> > > return ret;
> > > }
> > >
> > > -serge
> >
> > Thanks, this is really nice! One question:
> > - I'll take it that we want to make mod_rdep() public. mod_rdep() will be
> > used
> > in lxc_destroy.c, lxccontainer.c and start.c. Problem is that in start.c
> > we do
> > not have a container to pass into mod_rdep(). Do you want me to rewrite
> > mod_rdep() to take in lxcpath and lxcname? If so, could we still use
>
> Ok, I'm not running on all cylinders, sorry.
>
> You don't want mod_rdep, you want mod_all_rdeps. So yes export that,
> make a struct lxc_container, lock it, and pass that to mod_all_rdeps
> which will dothe mod_rdeps for you.Ha, no worries. :) Ok, just to be clear, where do we fit mod_all_rdeps() in with start.c? We do not have a struct lxc_container in start.c only struct lxc_handler. I assume there must be some reason for this. > > > disk_lock() and mem_lock by e.g. calling lxc_container_new(lxcname, > > lxcpath) > > and then calling disk_lock() or mem_lock() after to protect the container? > >
signature.asc
Description: PGP signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
