deleted subvols don't go away?

Hey.

Just wondered...
On a number of filesystems I've removed several subvoumes (with -c)... even called btrfs filesystem sync afterwards... and waited quite a while (with the fs mounted rw) until no disk activity seems to happen anymore.

Yet all these fs shows some deleted subvols e.g.:

btrfs subvolume list -pagud /thefs
ID 5 gen 10502 parent 0 top level 0 uuid - path <FS_TREE>/DELETED

Any ideas?

btw: seems (at least) the -d option is missing from the manpages at least until progs version 4.12

Cheers,
Chris.

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

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).

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

Thanks...

Still a bit strange that it displays that entry... especially with a generation that seems newer than what I thought was the actually last generation on the fs.

Cheers,
Chris.

Snapshot destroy is a 2-phase process. The first phase deletes just the root references. After it you see what you've described. Then, later, when the cleaner thread runs again the snapshot's root item is going to be deleted for good and you no longer will see it.

It's worth noting also that if the subvol is still used in some way
(still mounted, nested subvol, processes with CWD in it, open files), then it won't be cleaned up until the usage stops. Basically the same behaviour as deleting a file. This could also explain the more recent than expected generation values.

Hugo.

Hugo Mills             | "Big data" doesn't just mean increasing the font
hugo@... carfax.org.uk | size.
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

Oh, that's pretty sweet -- it means there's actually a way to reliably wait for cleaner work to be done on all deleted snapshots before unmounting the FS. I was wondering about that recently for some transient filesystems (which get mounted, synced to, snapshot-created/removed, then unmounted). Now can just loop with a few second sleeps until btrfs sub list -d $PATH comes up empty.

With respect,
Roman