Re: BTRFS-errors on a 20TB filesystem

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1809 bytes --]



On 2020/7/6 下午7:33, Paul-Erik Törrönen wrote:
> 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.

Oh, that explains the amount of problems...

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

If the dump contains confidential filenames, then feel free to send it
only to me.
Or feel free the censor the filenames if you want to send it to the mail
list.

Thanks,
Qu
> 
>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]