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
