On 20/08/17 11:43, Mikael Abrahamsson wrote: > On Sun, 20 Aug 2017, Gionatan Danti wrote: > >> It can be even worse: if fsck reads from the disks with corrupted data >> and tries to repair based on these corrupted information, it can blow >> up the filesystem completely. > > Indeed, but as far as I know there is nothing md can do about this. What > md could do about it is at least present a consistent view of data to > fsck (which for raid1 would be read all stripes and issue "repair" if > they don't match). Yes, this might indeed cause corruption but at least > it would be consistent and visible. > Which is exactly what my "force integrity check on read" proposal would have achieved, but that generated so much heat and argument IN FAVOUR of returning possibly corrupt data that I'll probably get flamed to high heaven if I bring it back up again. Yes, the performance hit is probably awful, yes it can only fix things if it's got raid-6 or a 3-disk-or-more raid-1 array, but the idea was that if you knew or suspected something was wrong, this would force a read error somewhere in the stack if the raid wasn't consistent. Switching it on then running your fsck might trash chunks of the filesystem, but at least (a) it would be known to be consistent afterwards, and (b) you'd know what had been trashed! Cheers, Wol -- 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
