RE: mismatch_cnt again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have been following this issue some, and I think this could be a cause for
silent corruption on RAID5 and RAID6.  I don't think this has been
mentioned, if so, sorry.

If data blocks can be changed in memory before written to disk, even if the
data blocks that were changed were never needed again from the disk, the
other related blocks in the stripe are at risk.  If the parity blocks are
computed, then the 1 data block in memory is changed, then the blocks are
written to disk, the parity would be wrong.  If a disk fails and is re-added
or replaced, the data block in that stripe will be computed using the
changed block giving a now corrupt value.  I am assuming the stripe has some
data blocks that have needed data and at least 1 that was not needed, and
that block that was not needed was changed before writing it to disk.  And
the disk that failed did not have the block that had been changed.

I have a hard time conveying my thought in text.  I hope you understand me.

Thanks for reading.

--
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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux