Am Fri, 15 Jul 2016 16:12:51 -0700 (PDT)
schrieb Eric Wheeler [off-list ref]:

Hello all,

If I create three subvolumes like so:

# btrfs subvolume create a
# btrfs subvolume snapshot a b
# btrfs subvolume snapshot b c

I get a parent-child relationship which can be determined like so:

# btrfs subvolume list -uq /home/ |grep [abc]$
parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
parent_uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad uuid
cb4768eb-98e3-5e4c-935d-14f1b97b0de2 path b parent_uuid
cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid
5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c

Now if I delete 'b', the parent_uuid of 'c' doesn't change to point
at 'a':

# btrfs subvolume delete b
# btrfs subvolume list -uq /home/ |grep [abc]$
parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
parent_uuid cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid
5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c

It cannot do that because b may have diverged from a.

Notice that 'c' still points at b's UUID, but 'b' is missing and the 
parent_uuid for 'c' wasn't set to '-' as if it were a root node (like
'a').

Is this an inconsistency?  Child parent_uuid's it be updated on
delete?

I think this is by design. This "missing" UUID is now no longer a file
system tree, it's just referencing blocks different between a and c at
the time of deleting b.

It would be nice to know that 'c' is actually a descendent of 'a',
even after having deleted 'b'.  Is a way to look that up somehow?

Actually it would also be interesting what happens with blocks in
deleted b after the blocks in c are unshared? Are they garbage
collected or do we have some orphan subvolume lying around which you
cannot get rid of?


-- 
Regards,
Kai

Replies to list-only preferred.