[lxc-devel] [PATCH] [RFC] snapshots: move snapshot directory (v3)

S.Çağlar Onur caglar at 10ur.org
Sun May 25 02:23:30 UTC 2014


Hey Serge,

On Sat, May 24, 2014 at 8:15 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
>> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
>> > Originally we kept snapshots under /var/lib/lxcsnaps.  If a
>> > separate btrfs is mounted at /var/lib/lxc, then we can't
>> > make btrfs snapshots under /var/lib/lxcsnaps.
>> >
>> > This patch moves the default directory to /var/lib/lxc/c/snaps.
>> > If /var/lib/lxcsnaps already exists, then use that.
>> >
>> > If we are deleting a container which has snapshots, we currently
>> > will delete the container itself and its rootfs, but not its
>> > snapshots.  This could be confusing for the user, and there is
>> > no option to c->destroy() to ask for different behavior.  So
>> > currently a user would have to delete all snapshots first, then
>> > delete the container.  Ideas for better handling this would be
>> > welcome, but we don't want to change the current api, so while
>> > adding a new c->destroy_full() would be ok, adding a flags
>> > argument to c->destroy(c, flags) is not.
>>
>> I'm thinking that
>>
>>       c->snapshot_destroy(c, NULL);
>>
>> should tell lxc to remove all snapshots.  So then at least we can
>>
>>       c->snapshot_destroy(c, NULL);
>>       c->destroy(c);
>>       lxc_container_put(c);
>>
>> as a way of making sure we delete the whole thing.
>
> I'm working on a full patch to go about it this way.

Sorry for being late in the game but I'm wondering would be make more
sense to introduce a new method called lxcapi_snapshot_destroy_all to
do lxcapi_snapshot_list followed by a loop to call
lxcapi_snapshot_destroy instead of overloading the snapname parameter?

> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

Best,
-- 
S.Çağlar Onur <caglar at 10ur.org>


More information about the lxc-devel mailing list