On 10/31/2015 08:18 PM, Philip Seeger wrote:
On 10/23/2015 01:13 AM, Erik Berg wrote:
So I intentionally broke this small raid6 fs on a VM to learn recovery
strategies for another much bigger raid6 I have running (which also
suffered a drive failure).
Basically I zeroed out one of the drives (vdd) from under the running
vm. Then ran an md5sum on a file on the fs to trigger some detection of
data inconsistency. I ran a scrub, which completed "ok". Then rebooted.
Now trying to mount the filesystem in degraded mode leads to a kernel
crash.
I've tried this on a system running kernel 4.2.5 and got slightly
different results.
And I've now tried it with kernel 4.3-rc7 and got similar results.
Created a raid6 array with 4 drives and put some stuff on it. Zeroed out
the second drive (sdc) and checked the md5 sums of said stuff (all OK,
good) which caused errors to be logged (dmesg) complaining about
checksum errors on the 4th drive (sde):
BTRFS warning (device sde): csum failed ino 259 off 1071054848 csum
2566472073 expected csum 3870060223
Same issue, this time sdd. The error message appears to chose a random
device.
This error mentions a file which is still correct:
Same issue.
However, the scrub found uncorrectable errors, which shouldn't happen in
a raid6 array with only 1 bad drive:
This did not happen, the scrub fixed errors and found no uncorrectable
errors.
But it looks like there are still some "invisible" errors on this (now
empty) filesystem; after rebooting and mounting it, this one error is
logged:
BTRFS: bdev /dev/sdc errs: wr 0, rd 0, flush 0, corrupt 199313, gen 0
However, this "invisible" error shows up even with this kernel version.
So I'm still wondering why this error is happening even after a
successful scrub.
Philip
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
