On 2020/5/22 上午7:48, Pierre Abbat wrote: > On Thursday, May 21, 2020 3:56:01 AM EDT Qu Wenruo wrote: >> That doesn't sound good. But according to your btrfs check result, your >> memory doesn't look good. >> There seems to be a memory bit flip. >> >> A full memtest is highly recommended. >> >> And since your hardware is not functioning reliable, everything can go >> wrong. > > There was a thunderstorm. The power blinked twice within a few minutes. That > could have easily caused the bit flip. > >>> UUID: 1f5a6f23-a7ef-46c6-92b1-84fc2f684931 >>> [1/7] checking root items >>> [2/7] checking extents >>> incorrect local backref count on 4186230784 root 257 owner 99013 offset >>> 5033684992 found 1 wanted 2097153 back 0x5589817e5ef0 >> >> Here, the 2097153 is 0x200001, it's an obvious bitflip. >> >> And since it's in extent tree, even write time tree checker can't detect it. >> >> But that problem is not a big thing, btrfs check --repair can fix it. >> >> Still, memtest first, only process to try repair after your memory is fixed. > > "btrfs check" gave me a "device busy" error. (When I booted the M.2, this was > caused by the hung mount process, but it happened even when I booted the flash > drive. I don't know why.) I couldn't repair it. I had to get a new drive and > recover the files to the new drive. > > Trying to mount the corrupt filesystem consistently hangs. That indicates a bug > in mount. How can I send you the corrupt filesystem so that you can debug > mount? Considering your btrfs check reports no serious problem, the hang looks strange. The remaining possibility is the log tree. You could try to boot using any liveCD with new enough kernel, then btrfs ins dump-super <device> | grep log_root If the result is not 0, then try btrfs rescue zero-log, then try mount again. Thanks, Qu > > Pierre >
Attachment:
signature.asc
Description: OpenPGP digital signature
