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': > > # 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
