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

[Hugo Mills <hugo@carfax.org.uk>]

[-- 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 --]