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