[lxc-devel] [PATCH] Add remove_snapshots_entry() (rebased - v2)

[Christian Brauner]

On Mon, Sep 14, 2015 at 02:50:39PM +0000, Serge Hallyn wrote:
> Quoting Christian Brauner (christianvanbrauner at 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 don't
> think we want to write one, but a program to show which snapshots exist
> would be good).
> 
> (Actually, there seems to be a bug right now - The sequence:
> 
> 	lxc-create -t download -n w1 -- -d ubuntu -r wily -a amd64
> 	lxc-clone -s -B overlayfs -o w1 -n w2
> 	lxc-snapshot -n w2
> 	lxc-snapshot -n w2 -r snap0
> 
> does not result in /var/lib/lxc/w2/snap0 being deleted, so a subsequent
> 
> 	lxc-destroy -n w2
> 
> is refused.

Has the bug been introduced by changes I made. It does not look like it as this
is also the behavior in stable-1.1. So what you want is to have the snapshot
deleted after having restored from it once? That seems not what we want. Btw, if
one would really like to have w2 removed there is always the option to do a
simple

        lxc-destroy -n w2 -s

which means remove including all snapshots...

> 
> Do you have time to either look into that, or raise an issue on github
> about it?
> 
> > called and the container in question is running, lxc-destroy will simply fail
> > with the warning that the clone is still running but lxc-destroy won't touch
> > the lxc_snapshots file. The offending container will then exit and delete the
> > container entry. lxc-destroy can then be called again and will delete the
> > remaining containers.
> > 
> > The strange case seems to be when we create another clone-snapshot while
> > another one shuts down. Does someone have any arguments against this way of
> 
> This should be fine, because mod_rdep does a container_disk_lock(c0).  So
> the inc and dec will be mutually exclusive.
> 
> > implementing it? Do we expect trouble? Do we need flocks in start.c and
> > lxccontainer.c?
> > 
> > Christian Brauner (1):
> >   Add remove_snapshots_entry()
> > 
> >  src/lxc/start.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 123 insertions(+)
> > 
> > -- 
> > 2.5.1
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150914/3d956216/attachment.sig>