Hey. Had the following on a Debian sid: Linux heisenberg 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux btrfs-progs v4.7.3 (It's not so long ago that I ran some longer memtest86+ on the respective system. So memory should be ok.) It was again a 8 TB SATA disk connected via USB3. SMART values are all just okay, the disk has some 600 head flying hours so not *that* extremely much. When doing another round of btrfs check on it (I only did some yesterday after the events described in the "strange btrfs deadlock" email I've sent to the earlier today) everything was still okay. This time, I got csum errors during the "checking extents" phase. There were always two identical lines of csum errors printed (with the same address, expect and actual csum. I've aborted btrfs check (after some 10-15 pairs of csum errors), repeated it... again csum errors. Aborted it again, blockdev --setro the device, mounted the fs and did a find /mnt/ > /dev/null on it.... seemed to all work fine. Unmounted and repeated the btrfs check... no errors this time (and I let it complete)... No messages/errors to the kernel log during the whole time. Any ideas what that could mean? Are there any known bugs in 4.7.3? Especially... if the csums errors might have occurred just because of some electronic glitch in the SATA/USB bridge (okay unlikely - I'd have expected that the lower bus levels show such errors - but who knows) what does btrfs check do if it encounters such csum errors? Trying to correct it (thereby possibly writing bad data in my case)? That the errors just went away isn't less worrying,... but I'd have expected that because of the blockdev --setro, there couldn't have been any auto-repairs or that like which would have corrected the csums. Any advice what I could/should do now? scrubbing[0]? Rather assuming faulty hardware. The data on the device is backuped (mostly), still it's pretty precious. Thanks, Chris. [0] I also have my hown SHA512 sums of all files on disk (in XATTRS) plus file lists of files that should be present (+/- some recent changes to the fs)... so I can do really very accurate checks whether the data is fully ok.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
