On Feb 13, 2020 at 22:01, Qu Wenruo wrote:
On 2020/2/13 上午8:26, Qu Wenruo wrote:On 2020/2/13 上午5:58, Samir Benmendil wrote:I've been getting the following "BTRFS errors" for a while now, the wiki [0] advises to report such occurrences to this list.Please provide the following dump: # btrfs ins dump-tree -b 194756837376 /dev/sda2 # btrfs ins dump-tree -b 194347958272 /dev/sda2BTRFS critical (device sda2): corrupt leaf: root=466 block=194756837376 slot=72 ino=1359622 file_offset=475136, extent end overflow, have file offset 475136 extent num bytes 18446744073709486080item 72 key (1359622 EXTENT_DATA 475136) itemoff 11140 itemsize 53 generation 954719 type 1 (regular) extent data disk byte 0 nr 0 extent data offset 0 nr 18446744073709486080 ram 18446744073709486080 extent compression 0 (none) Also obvious underflow.BTRFS critical (device sda2): corrupt leaf: root=466 block=194347958272 slot=131 ino=1357455 file_offset=1044480, extent end overflow, have file offset 1044480 extent num bytes 18446744073708908544item 131 key (1357455 EXTENT_DATA 1044480) itemoff 6497 itemsize 53 generation 952602 type 1 (regular) extent data disk byte 0 nr 0 extent data offset 0 nr 18446744073708908544 ram 18446744073708908544 extent compression 0 (none) As you can see, 18446744073708908544 = -653072, which means it overflows. Both look like a bug in older kernels. Since currently btrfsprogs can't detect nor fix it yet, the only way is to delete the offending files. You can use the inode number 1357455, and root id 466 to locate the offending files, and delete it using older kernels. (root id is your subvolume id, which is shown in `btrfs subv list`. inode number can be passed to `find` command using `-inum` option)
I deleted the offending file for inode 1357455 using kernel 4.4.165.However `find` did not return any results for inode 1359622. The newer kernel doesn't seem to complain about that anymore though.
Thank you for you help Qu. Regards Samir
Attachment:
signature.asc
Description: PGP signature
