Re: BTRFS claims that empty directory is not empty and refuses to delete it

[Martin Steigerwald <Martin@lichtvoll.de>]

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

Am Dienstag, 15. Juli 2014, 11:01:25 schrieb Hugo Mills:
> On Tue, Jul 15, 2014 at 11:09:53AM +0200, Martin Steigerwald wrote:
> > Hello!
> > 
> > This is with 3.16-rc4 – stepped back to this one after having two hangs in
> > one day with 3.16-rc5, see other thread started by me:
> > 
> > martin@merkaba:~/Zeit/undeletable/db_data> ls -lid akonadi
> > 450598 drwx------ 1 martin martin 1232 Jun 22 14:11 akonadi
> > martin@merkaba:~/Zeit/undeletable/db_data> ls -lai akonadi
> > insgesamt 0
> > 450598 drwx------ 1 martin martin 1232 Jun 22 14:11 .
> > 450595 drwxr-xr-x 1 martin martin   14 Jun 22 14:11 ..
> > martin@merkaba:~/Zeit/undeletable/db_data> LANG=C rmdir akonadi
> > rmdir: failed to remove 'akonadi': Directory not empty
> > martin@merkaba:~/Zeit/undeletable/db_data#1> LANG=C rm -r akonadi
> > rm: cannot remove 'akonadi': Directory not empty
> > martin@merkaba:~/Zeit/undeletable/db_data#1> LANG=C rm -rf akonadi
> > rm: cannot remove 'akonadi': Directory not empty
> > martin@merkaba:~/Zeit/undeletable/db_data#1>
> > 
> > 
> > Whats this?
> > 
> > I had this weeks ago already and just moved it out of the way at that
> > time,
> > just now stumbled upon it again.
> 
>    That is symptomatic of a bug from a couple of kernel versions ago
> (now fixed, so it won't happen again). It it is that bug, then btrfs
> check will report something along the lines of "directory isize
> wrong", and the problem can be fixed by running a btrfs check
> --repair. If you get anything else from btrfs check (or it checks
> cleanly), then let us know first.

Thanks, Hugo. Just a heads up I was able to fix the issue and how btrfs check 
improved from 3.14.1 to 3.16 :)

Some time ago I can btrfs check 3.14.1 and while it fixed this undeleteable file 
it was able to fix another issue with that BTRFS fs:

enabling repair mode
Checking filesystem on /dev/msata/home
UUID: […]
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
reset isize for dir 435395 root 256
reset isize for dir 435397 root 256
reset isize for dir 450598 root 256
reset isize for dir 2654270 root 256
btrfs: volumes.c:948: btrfs_alloc_chunk: Assertion `!(ret)' failed.
zsh: abort      btrfs check --repair /dev/msata/home


This one was still there:

Checking filesystem on /dev/msata/home
UUID: […]
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
root 256 inode 5759476 errors 200, dir isize wrong
found 37709498062 bytes used err is 1
total csum bytes: 130574180
total tree bytes: 2897543168
total fs tree bytes: 2396323840
total extent tree bytes: 309051392
btree space waste bytes: 538971257
file data blocks allocated: 2757585866752
 referenced 135559811072
Btrfs v3.14.1

And it didn´t want to fix it at all, asserting all along.

enabling repair mode
Checking filesystem on /dev/msata/home
UUID: […]
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
btrfs: volumes.c:948: btrfs_alloc_chunk: Assertion `!(ret)' failed.


However

merkaba:/home/martin/Zeit> rm -r undeletable/

worked okay.


And now btrfs check 3.16 also cleaned up the last error:

merkaba:~> btrfs check /dev/msata/home
Checking filesystem on /dev/msata/home
UUID: […]
checking extents
checking free space cache
checking fs roots
root 256 inode 5759476 errors 200, dir isize wrong
found 51387055905 bytes used err is 1
total csum bytes: 128640084
total tree bytes: 2901934080
total fs tree bytes: 2398830592
total extent tree bytes: 306806784
btree space waste bytes: 547937419
file data blocks allocated: 2744207491072
 referenced 129598066688
Btrfs v3.16


merkaba:~#1> btrfs check --repair /dev/msata/home
enabling repair mode
Checking filesystem on /dev/msata/home
UUID: […]
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
reset isize for dir 5759476 root 256
checking csums
checking root refs
found 51387055905 bytes used err is 0
total csum bytes: 128640084
total tree bytes: 2901934080
total fs tree bytes: 2398830592

I made sure the error is gone by doing another check and it is gone indeed.


BTW I find "found 51387055905 bytes used err is 0" a bit ambigious. While one 
can say "err is 0" means no error, people may wonder whether there is an error 
or not. I assume that this is display a mismatch between the found bytes and 
the bytes that are *supposed* to be there.

This all was on 3.17-rc2 with fixcompwrite patch v3 from Liu.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]