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

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

[Goffredo Baroncelli]

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

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

[Goffredo Baroncelli]

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

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

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

[Chris Murphy]

On Fri, Mar 20, 2015 at 1:34 PM, Goffredo Baroncelli <kreijack@libero.it> 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

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

[Lennart Poettering]

On Fri, 20.03.15 18:08, Chris Murphy (lists@colorremedies.com) wrote:

> 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.

containers are recursively stackable, hence having toplevel subvolumes
doesn't work, since the containers should be able to have
subcontainers of their own...

Also, it kinda defeats the whole point of btrfs' subvolume concept,
where subvolumes are little more than special directories.

Lennart

-- 
Lennart Poettering, Red Hat

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

[Chris Murphy]

On Sun, Mar 22, 2015 at 10:53 PM, Lennart Poettering
<mzerqung@0pointer.de> wrote:
> On Fri, 20.03.15 18:08, Chris Murphy (lists@colorremedies.com) wrote:
>
>> 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.
>
> containers are recursively stackable, hence having toplevel subvolumes
> doesn't work, since the containers should be able to have
> subcontainers of their own...
>
> Also, it kinda defeats the whole point of btrfs' subvolume concept,
> where subvolumes are little more than special directories.

They're much more than that, they're a separate fs tree. They're maybe
something between a completely separate filesystem volume, and a
directory. They each have their own inodes, so it's possible (if not
likely) that on a Btrfs volume an inode will point to multiple files
in different subvolumes.

http://marc.info/?l=linux-btrfs&m=137462926329422&w=2

-- 
Chris Murphy