On Fri, Mar 20, 2015 at 1:34 PM, Goffredo Baroncelli <[email protected]> wrote: > Hi Chris, > On 2015-03-20 02:27, Chris Murphy wrote: >> Short version: >> ------------------ >> Instead of machinectl clone using btrfs snapshots, or even needing >> to store things in a var/lib/machines Btrfs subvolume, does it meet >> the requirements for Btrfs optimization to do this with cp -a >> --reflink instead? >> >> Why? Nested subvolumes are confusing. And nested subvolumes are >> excluded from snapshots. Subvolume B inside of Subvolume A, will not >> be snapshot or rolled back, if I snapshot Subvolume A and subsequently >> rollback to the snapshot of A. > > Personally I prefer this kind of behavior. Each subvolumes may have its life > cycle so a rollback on a volume doesn't means that the other also need it.
Sure but now it's missing if you do a rollback, or if you mount any different root tree, so immediately special handling is needed. If machines is a subvolume at the top level, it can always be mounted at /var/lib/machines regardless of which root is used. I also think this is more consistent with http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html specifically the section "What We Propose" when it comes to the location and naming convention for Btrfs subvolumes. > I think that a "cp --reflink" is slower than a snapshot, because all the > metadata still have to be copied. Another disadvantage, is that a snapshot > and its parent could be "easily" [3] compared; the same would be not true if > a cp --reflink is used. If it's containers themselves being snapshot, then /var/lib/machines isn't really what needs to be snapshot, it's the individual containers themselves that belong in a subvolume so they can be individually snapshot/cloned. -- Chris Murphy _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
