[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 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
recent patches by me to lxc-destroy when I do:

        lxc-clone -s -B overlayfs -o w1 -n w2

the snapshot-clone will be registered in the lxc_snapshots file and when I call

        lxc-destroy -n w1 -s

the original container including all it's snapshot-clones will be destroyed and
deleted from the lxc_snapshots file. This is done by having lxc-destroy open the
lxc_snapshots file of the original container, reading in all snapshot-clone
entries in and deleting them.

> 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.
> 
> Do you have time to either look into that, or raise an issue on github
> about it?

I'll take a look tonight. Don't know how fast I can fix this.

> 
> > 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/0663fecd/attachment.sig>