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@xxxxxxxxxxxxxxxxxx>: > > > 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:
signature.asc
Description: Digital signature
