Re: booting btrfs

[Chris Murphy]

On Oct 15, 2013, at 8:45 PM, Andrey Borzenkov <address@hidden> wrote:

> В Tue, 15 Oct 2013 13:47:14 -0600
> Chris Murphy <address@hidden> пишет:
> 
>> 
>>> I'm not sure when and how top level may become != 5.
>> 
>> starting where you left off with the sub2 subvolume mounted
>> 
>> # btrfs subvol create /mnt/nested
>> # btrfs subvol list /mnt
>> ID 262 gen 135 top level 5 path dir1/sub1
>> ID 263 gen 140 top level 5 path dir2/sub2
>> ID 264 gen 140 top level 263 path nested
>> 
> 
> Now try to remount with subvolid=0 and you will see that all subvolumes
> have top level == 5.

But the path is also different:

ID 264 gen 165 top level 5 path dir2/sub2/nested

So this is consistent behavior. From the top level 5 the path is 
dir2/sub2/nested, whereas from top level 263 the path is nested. Means the same 
thing.


> Now "parent" is more interesting because it really tells us parent
> subvolume and it permanent on-disk property.

Yes I wish there were some metadata support so that it's possible for the 
application layer to understand the relationship between subvolumes better; 
e.g. so that all snapshots for an OS can be co-located in a listing, and sorted 
by recency. That way it's possible to do rollbacks at boot time to the next 
most recent "snapshot" of the system. It looks like right now this is up to 
naming and hierarchy strategy.

Presently, at least one OS installer becomes confused and lists, without 
distinction, every OS snapshot regardless of location as if it were a unique 
installation. So a file system with 50 snapshots of rootfs, looks in the 
installer as if there are 50 unique installations of the OS. Confusing.

However, an explicit "parent" concept might be difficult because a snapshot of 
a subvolume is a subvolume. I can delete either the original "parent" or the 
new snapshot and the other remains intact. The "parent" does not need to be 
retained as a backing for the snapshot. So really a snapshot is not as much a 
specific thing as it is an activity, and this same behavior applies to the new 
LVM thin provisioning snapshots as well.

Chris Murphy