Re: [systemd-devel] systemd and nested Btrfs subvolumes

[Goffredo Baroncelli <kreijack@inwind.it>]

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.

In the past [2] I proposed a patch to introduces a recursively snapshot; but it was unnoticed :-(

[...]
> Can clone instead use cp -a --reflink instead of using snapshots? Can
> subvolumes be entirely avoided?

[...]

> So back to cp -a --reflink as a work around for both paradigms? Does
> this method of cloning meet the requirements for systemd containers?
> If so, it works on both the RH/Fedora and the openSUSE layouts.
> Meaning the var/lib/machines subvolume isn't needed, just use cp -a
> --reflink on either directories or files, and it's almost as fast as a
> btrfs snapshot.

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. 

> 
> 
> 
> [1]
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg42333.html
> 
> 


[2] http://comments.gmane.org/gmane.comp.file-systems.btrfs/30119
[3] "btrfs find-new" and "btrfs send" do that

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5