btrfs-progs
btrfs-progs copied to clipboard
Contradicting information when trying to delete a directory.
$ rm -R reports/
rm: cannot remove 'reports/tests/test/classes': No such file or directory
rm: cannot remove 'reports/tests/test': Directory not empty
So the directory classes is now in a Schroedinger state. In the meantime, btrfs check reports that everything is normal:
~$ sudo btrfs check --progress --force /dev/nvme0n1p7
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/nvme0n1p7
UUID: 08b28308-9a51-4a07-ab2e-3bdcda274b9c
[1/7] checking root items (0:00:00 elapsed, 901937 items checked)
[2/7] checking extents (0:00:05 elapsed, 94297 items checked)
[3/7] checking free space tree (0:00:01 elapsed, 215 items checked)
[4/7] checking fs roots (0:00:10 elapsed, 76516 items checked)
[5/7] checking csums (without verifying data) (0:00:00 elapsed, 210994 items checked)
[6/7] checking root refs (0:00:00 elapsed, 3 items checked)
[7/7] checking quota groups skipped (not enabled on this FS)
found 214466875392 bytes used, no error found
total csum bytes: 165947780
total tree bytes: 1544814592
total fs tree bytes: 1257734144
total extent tree bytes: 83263488
btree space waste bytes: 256121061
file data blocks allocated: 312808062976
referenced 214539571200
This might be a new kernel bug. What kernel version is this?
If both of these statements were true:
- this filesystem has ever been mounted on a kernel version earlier than 5.16
- you can remove the directory successfully using
rmdir reports/tests/test, ignoring the object namedclasses
then this would be the result of a known bug where ghost dirents (filenames without an associated inode) get left behind during log replay after a crash. The fix for that bug is in kernel 5.16 and newer. Affected directories can be removed with rmdir despite the ghost dirents.
It looks like a new bug because:
btrfs checkcan detect and report ghost dirents, but in this case it did not.rm -Rappears to have attemptedrmdiralready, and in this case it failed.
The linux kernel being used is 6.2.6-76060206
I have the option to upgrade to 6.4.6-76060406, is there a significant change between btrfs used in these 2 versions?
I wasn't aware that btrfs are committed into the kernel
I don't have anything to add what Zygo wrote. Otherwise if you want to know about changes overview, you can find it at https://btrfs.readthedocs.io/en/latest/Kernel-by-version.html but it may not mention all individual bugs fixed. You can expect significant changes between major versions, 6.2 -> 6.4, bug fixes between minor versions 6.2.1 -> 6.2.2.