Aand I messed up by sending this to the person only. Sorry for that.
On 2020-07-06 13:55, Qu Wenruo wrote:
Some older extents are affected by older kernel not handling extents
length correctly.
18446744073709481984 = -69632, which means there is some underflow.
Recent upstream kernel caught it and reject the whole tree block to
prevent furhter problem.
Ok, so if I understand this correctly, the issue is essentially created
by using a new (5.x) kernel, whereas the server was running 3.10 (CentOS
7.8 version with btrfs-support) -> CentOS 8.2.
Would you please provide the dump for this bytenr?
I'm a little interested in this.
I'll provide you the dumps you requested in the evening. Should I email
them to the list, or directly to you?
Thanks for your detailed report, this would help us to enhance
btrfs-progs to fix them.
Glad to be of help.
For now, you can just mount them with older kernel, find the offending
inode using the ino number in the dmesg, and delete the offending file.
With all offending inodes deleted, the fs would come back to normal
status.
Ah, well. As mentioned in the previous email, I reinstalled the server
with CentOS8. Unfortunately RHEL/CentOS8 dropped support for btrfs (as
well as megaraid_sas), so I will be running this machine on the UEK
kernel for the forseeable future and planning on replacing/recreating
the FS on the partition.
Poltsi
