Hi Bruce, On 11/14/2016 01:50 AM, Bruce Merry wrote: > Okay, I'll give that script a go to increase my kernel timeout. If I > understand correctly, it's not the end of the world if the drive > doesn't support SCTERC, provided I have a long kernel timeout (and > when things go wrong it might take much longer to recover, but I can > live with that). Is that correct? Yes. >> 2) Trim. Well-behaved drive firmware guarantees zeros for trimmed >> sectors, but many drives return random data instead. Zing, mismatches. >> It's often unhelpful with encrypted volumes, as even well-behaved >> firmware can't deliver zeroed sectors *inside* the encryption. > > Weee, sounds like fun. I hope it's that. Is there any way to tell > which blocks mismatch, so that I can tell which files are in trouble > (assuming I can figure out how to map through LVM, LUKS and > debuge2fs). The check operation doesn't log the sector addresses, unfortunately. At least I don't see any such operation in the code that increments mismatch count. Not even a tracepoint. Hmmm. In the meantime, run a "repair" scrub instead of a "check" scrub to affirmatively force no mismatches. (Writes first member of mirrors to the others.) Phil -- 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
