[lxc-devel] [PATCH 1/1] lxc-create: add zfs support

[Stéphane Graber]

On 04/21/2013 03:37 PM, Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
>> <ping> Any feedback on this patch?
>>
>> I also have a question on behavior details.  Until now, we've set up
>> btrfs containers so that $lxcpath is a subvolume, and then each
>> $rootfs is a subvolume.  With zfs, per Papp's request, we're making
>> the (zfs equivalent of a subvolume) at the $lxcpath/$lxc_name.  So
>> that means when we make a snapshot clone, we'll be doing them
>> differently for different filesystems.
>>
>> I don't really care which we do - and even if we keep them different
>> for hysterical raisins it's not biggie technically, since the
>> filesystems have to be handled differently at clone anyway.  But
>> it'll be harder to explain to users what's going on.
>>
>> With the btrfs way, when we snapshot-clone a container we have to
>> manually copy all the config and hooks files.  We have to process
>> them anyway (s/oldname/newname etc) though.  With the zfs way we
>> wouldn't have to copy them - so files which we didn't predict won't
>> be copied.  That may be a good thing - if we didn't predict it, then
>> we probably didn't process it anyway so it may not be safe.  Still
>> the zfs way feels elegant...
> 
> To reply to myself,
> 
> as we also support snapshot-clones of lvm, and soon qcow and qed
> based containers, and those will only snapshot the rootfs, if we
> want behavior with all backing stores to be consistent then zfs
> would need to change to only snapshot the rootfs, not $lxcpath/$lxc_name.
> 
> -serge

I'm not a big user of lxc-clone (yet) but I think as we redesign that
part of the code, consistency across backend should be a primary goal
even if that causes some slight changes in behaviour from previous
implementations.


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130421/74c29b31/attachment.pgp>