Re: Scrub aborts due to corrupt leaf

[Larkin Lowrey <llowrey@nuclearwinter.com>]

On 12/31/2018 7:12 PM, Qu Wenruo wrote:
>
> On 2018/12/31 下午11:52, Larkin Lowrey wrote:
>> On 10/11/2018 12:15 AM, Chris Murphy wrote:
>>> Is this a 68T file system? Seems excessive.
>>> Haha, by excessive I mean nuking such a big fs just for being unable
>>> to remove the space tree. I'm quite sure the devs would like to get
>>> that crashing bug fixed, anyway.
>> A second FS just started failing. I never had this much trouble with
>> space cache v1.
>>
>> This host had a DIMM failure a couple of weeks ago which caused the
>> system to halt due to uncorrectable ECC error(s).
> That looks like a pretty possible cause for the corruption.
>
> Like strange items in your extent tree of your other fs, if your memory
> is unreliable, all your fs is possible corrupted.
>
> And for the victim of memory corruption, the hotter tree block the
> easier to be a victim.
>
> For both case, the corruption happens at extent tree, which matches the
> symptom.

I hope you're not saying that BTRFS bypasses ECC protections. That would 
be very bad indeed. So, since the CPU immediately halted when it 
detected a memory error that could not be corrected, memory was not 
corrupted and the worst that happened was a write to disc that did not 
complete.

> Please do a btrfs check on all your filesystems.

# btrfs check /dev/Cached/Nearline
Opening filesystem to check...
Checking filesystem on /dev/Cached/Nearline
UUID: 68d31d5f-97a2-4a73-a398-c7c13ff439a5
[1/7] checking root items
checksum verify failed on 271262429573120 found 1BA4548E wanted D105DF84
checksum verify failed on 271262429573120 found 1BA4548E wanted D105DF84
bad tree block 271262429573120, bytenr mismatch, want=271262429573120, 
have=17478763091281320157
ERROR: failed to repair root items: Input/output error

--Larkin