deleted subvols don't go away?

deleted subvols don't go away?

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: deleted subvols don't go away?

[Janos Toth F.]

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

Re: deleted subvols don't go away?

[Nikolay Borisov]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: deleted subvols don't go away?

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: deleted subvols don't go away?

[Nikolay Borisov]

On 28.08.2017 11:07, Christoph Anton Mitterer wrote:
> 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.

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.

> 
> Cheers,
> Chris.
> 

Re: deleted subvols don't go away?

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Mon, Aug 28, 2017 at 03:03:47PM +0300, Nikolay Borisov wrote:
> 
> 
> On 28.08.2017 11:07, Christoph Anton Mitterer wrote:
> > 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.
> 
> 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          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: deleted subvols don't go away?

[Roman Mamedov]

On Mon, 28 Aug 2017 15:03:47 +0300
Nikolay Borisov <n.borisov.lkml@gmail.com> wrote:

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

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