Quoting Stéphane Graber (stgra...@ubuntu.com): > On 04/21/2013 03:37 PM, Serge Hallyn wrote: > > Quoting Serge Hallyn (serge.hal...@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.
Ok, there are two ways we can think about containers. We can think of a container, including rootfs and config files, as 'a thing', so that if I want to move a container from one system to another, for instance, I want to move those together. That sort of fits the zfs model (predictable for obvious reasons :). On the other hand there are several places where just the rootfs makes more sense. 1) cloud image model, where we download a prepared rootfs on a qcow qemu-nbd fs, which we can use on bare metal, in kvm, or in a container. As I say I expect nbd to be a supported backend, so it would suck to have to modify the downloaded image before we can use it. 2) lots of people seem to want to keep rootfs in separate place from config files (not sure this is a strong rationale) 3) if we want to run many snapshotted containers from one rootfs with their own deltas, do we feel the configuration files are relevant for snapshotting as well? Anyway so far I haven't heard anyone but me object to such a switch, so I'll wait another day or so and if noone else does, then it sounds like an easy decision. thanks, -serge ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
