> This is a very invasive change that you ask, conceptually, > man-hours-wise, performance-wise, ondisk-format wise, space-wise Yes ... I'm aware of possibly high number of man-hours. If we talk about space ... 0.78% is not so invasive, is it? On-disk format ... interleaving chunks with checksum sectors doesn't seem to me a complicated math ... chunk_starting_sector = chunk_number * (chunk_size_in_sectors + 1) ... of course this is relative to the chunk area offset. > also it really should stay at another layer, preferably below the > RAID but how would you like to implement that if the lower level is known to be unreliable enough? > (btrfs and zfs do this above though). Btrfs and zfs has it's own RAID layer, so there's no need for underlying MD-RAID. But I haven't studied how exactly it's done there. > This should probably be a > DM/LVM > project. LVM ? How do you want to implement that in LVM? You would create two big PVs with two big logical partitions protected by checksums? The mdraid layer would be built on top of these, right? That could possibly work too if LVM returns read errors for blocks with incorrect checksums. I'm not fully against that idea. > > Drives do this already, they have checksums (google for > reed-solomon). > If the checksums are not long enough you should use different drives. > But in my life I never saw a "silent data corruption" like the one > you say. I believe I've mentioned my experience with such nasty HDD behaviour in my previous email. I also don't like that, but it apparently happens and we can't rely on the proper hardware functioning especially when it's unreliable by nature. Regards, Jaromir. -- 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
