For raid5 it's different. No single chunks are created while copying
files to a degraded volume.
And the scrub produces very noisy kernel messages. Looks like there's
a message for each missing block (or stripe?), thousands per file. And
also many uncorrectable errors like this:
[267466.792060] f23s.localdomain kernel: BTRFS error (device dm-8):
unable to fixup (regular) error at logical 3760582656 on dev /dev/dm-7
[267467.508588] f23s.localdomain kernel: scrub_handle_errored_block:
401 callbacks suppressed
[root@f23s ~]# btrfs scrub start /mnt/1/
ERROR: there are uncorrectable errors
[root@f23s ~]# btrfs scrub status /mnt/1/
scrub status for 51e1efb0-7df3-44d5-8716-9ed4bdadc93e
scrub started at Fri Apr 8 14:35:25 2016 and finished after 00:11:26
total bytes scrubbed: 3.21GiB with 45186 errors
error details: read=95 super=2 verify=8 csum=45081
corrected errors: 44935, uncorrectable errors: 249, unverified errors: 0
Subsequent balance and scrub have no messages at all. So...
uncorrectable? Really? That's confusing.
FYI, for a scrub with no errors it's 4m24s, but with the same data and
1/2 of it needing to be rebuilt during the scrub took 16m4s, so about
4x longer to reconstruct. Seems excessive.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
