On 2/12/19 12:21 PM, Robin Hill wrote: > I think you're wrong there - my understanding is that mismatches on > RAID1 are very common under certain circumstances, but (as far as I'm > aware) don't cause any risk to data. > > From what I recall of the details, unlike other RAID levels, RAID1 > doesn't bother taking a copy of the buffer to be written (as it's going > to write the same data to all drives anyway), which means the data can > be changed between writes to the different disks. The mismatch only > happens if there's no further write command issued after the change > (otherwise the changed data would get rewritten to all disks), which > means the data written won't be re-used. This is most common with swap, > but can happen with other applications which write temporary data to > disk. This seems correct. I once closely examined mismatched blocks on a RAID 1 array on one of our mail servers, and found that they were one byte differences caused by Postfix doing this: 1) writing a queue file with the "has been delivered to recipient X" byte set to 0; 2) issuing a write that would change that byte to 1; 3) deleting the file. Step 2 occasionally gets written to only one of the disks, with the others ignoring the write because the step 3 deletion happens to occur before they get around to the step 2 write. But that's harmless; as you say, it appears to happen only with blocks that by definition are never going to be re-read. You can imagine all sorts of things that do something similar: for example, you could append a few bytes to the end of a file, then truncate the file to a smaller size, and it wouldn't matter whether those bytes ever reached all the disks. Because of that, mismatched blocks on a RAID 1 array don't necessarily seem to be an indicator of a problem. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
