Re: Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol

[Kai Krakow <hurikhan77@gmail.com>]

Am Fri, 15 Jul 2016 16:12:51 -0700 (PDT)
schrieb Eric Wheeler <btrfs@lists.ewheeler.net>:

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