Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol

Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol

[Eric Wheeler]

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

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?

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?


This is running 4.1.15, so its a bit behind.  If this is fixed in a later 
version then please let me know that too.  Thanks!


--
Eric Wheeler

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

[Kai Krakow]

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.

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

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

On Sat, Jul 16, 2016 at 12:18:18PM +0200, Kai Krakow wrote:
> 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':

   Correct -- the parent is the subvol that the snapshot was made
from. After you make a snapshot, the snapshot and its original
subvolume are entirely equal partners, so there's no parent-child
relationship between them for purposes of data storage or anything
like that. The parent_uuid field is only used by send -p to ensure
correctness, and for nothing else.

> > # 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?

   It's not inconsistent. I think it just doesn't mean what you
thought it did. :)

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

   They're GCed. Extents are simply reference counted -- it doesn't
matter how those references got there, or in what order. When the
reference count drops to zero, the extent is cleaned up.

   Hugo.

-- 
Hugo Mills             | Great oxymorons of the world, no. 9:
hugo@... carfax.org.uk | Standard Deviation
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]