On Sep 14, 2012, at 1:45 AM, Niccolò Belli wrote: > I also would like to know if the raid1 will *surely* use data from the other disk to write on the broken sector after a CHECK. Not according to documentation. In normal operation, and for a repair, what you describe is correct. But not for check. > I mean, i did nothing even after a read error on md0 with a "failed command: READ DMA" in dmesg (possibly because after a few reads it succeeded reading?). Possibly. Possibly the disk firmware finally was able to relocate that sector's data. Possibly its ECC thinks it has reconstructed the data on that sector, but in fact the data is corrupt. > I read that when raid1 is in doubt there is a 50%-50% chance it uses data from the good disk, wouldn't be better to fail the broken disk and then re-add it to the array? I don't know what this means. But I think there's a misunderstanding about disk behavior. A disk's reliability is not always a binary condition. Most often it's a continuum, because sector problems are masked by disk's ECC, and they go entirely unreported to the kernel, and thus md. This includes the case when the disk ECC detects an error, and thinks it has corrected it, but actually returns bogus (corrupt) data rather than a read error; as well as when disk ECC does not detect an error at all, but the data is in fact corrupt. The md driver has no practical choice but to trust the data the disk returns, absent an error. So I'm confused by what you mean by "when raid1 is in doubt" and what you mean by this "50/50 chance" part. When the disk ECC detects an error, and fails to correct it, only then will it report a read error to the kernel, and then md will get that data elsewhere. There is no good reason for md to mark a 99.99% correctly performing disk as faulty. If it did this, you've unnecessarily abandoned those 99.99% useful sectors, and in so doing have significantly reduced redundancy. There's a reason why there are check and repair functions, rather than wholesale discarding an otherwise valuable disk with a handful of bad sectors (or even one), and the ensuing loss of redundancy. Check is read only so it will be faster than repair, is a good reason to use check frequently and repair less frequently unless check warrants it. And there's good reason to include some smartd periodic testing as well since there are parts of the disk that md check/repair can't test *and* because the disk ECC masks problems, whereas SMART should report them. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
