On 28.08.2017 06:43, Janos Toth F. wrote:
> ID=5 is the default, "root" or "toplevel" subvolume which can't be
> deleted anyway (at least normally, I am not sure if some debug-magic
> can achieve that).
> I just checked this (out of curiosity) and all my Btrfs filesystems
> report something very similar to yours (I thought DELETED was a made
> up example but I see it was literal...):
>
> ~ # btrfs sub list -a /
> ID 303 gen 172881 top level 5 path <FS_TREE>/gentoo
> ~ # btrfs sub list -ad /
> ID 5 gen 172564 top level 0 path <FS_TREE>/DELETED
This seems to be coming form the userspace tools, specifically the
filter_and_sort_subvol() function. So this function in turn calls
resolve_root and if it returns -ENOENT, meaning it couldn't resolve a
root. Then DELETED is returned.
On a quick inspection of the code it seems that even for deleted
subvolumes btrfs still retains the ROOT_ITEM for the subvolume but since
all ROOT_BACKREF are deleted then the name of the tree cannot be
resolved (since it's stored in the root_backref). For example I did:
btrfs subvolume create /media/scratch/subvol1 && sync
btrfs inspect-internal dump-tree -t root /dev/vdc
item 14 key (258 ROOT_ITEM 0) itemoff 12972 itemsize 439
generation 11 root_dirid 256 bytenr 29949952 level 0 refs 1
lastsnap 0 byte_limit 0 bytes_used 16384 flags 0x0(none)
uuid 217fd861-4606-1146-b5ee-59fba8d37f8c
ctransid 11 otransid 10 stransid 0 rtransid 0
drop key (0 UNKNOWN.0 0) level 0
item 15 key (258 ROOT_BACKREF 5) itemoff 12947 itemsize 25
root backref key dirid 256 sequence 4 name subvol1
Afterwards, I deleted the subvolume:
btrfs subvolume delete -v /media/scratch/subvol1/ && sync
item 13 key (258 ROOT_ITEM 0) itemoff 12997 itemsize 439
generation 11 root_dirid 256 bytenr 29949952 level 0 refs 0
lastsnap 0 byte_limit 0 bytes_used 16384 flags
0x1000000000000(none)
uuid 217fd861-4606-1146-b5ee-59fba8d37f8c
ctransid 11 otransid 10 stransid 0 rtransid 0
drop key (0 UNKNOWN.0 0) level 0
>
> I guess this entry is some placeholder, like a hidden "trash"
> directory on some filesystems. I don't think this means all Btrfs
> filesystems forever hold on to their last deleted subvolumes (and only
> one).
> --
> 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
>
--
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
