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 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 > >
signature.asc
Description: PGP signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel