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