Guy Watkins wrote:
} open tempfile
} write tempfile
} raid1 starts to commit the block
} write some more changing the block
} raid1 writes the 2nd copy of the block
} delete file
} fs never recommits the dirty page
}
} Personally I don't really buy that scenario. At least not in the
} frequency mismatches occur.
}
}
} MfG
} Goswin
If someone can map a mismatch to a file, the debate would be over.
Simple test: create a three way raid-1. Run it on a heavily used ext3
file system for a few days, until it has 3-4k mismatch count. Shut it
down gracefully. Now
- run e2fsck -n on each of the parts, to prove the f/s is not corrupt
- mount on partition, using ext2 type, ro,noatime[1]
- do an md5sum on every file and put the output in a file[2]
(on another f/s, obviously)
- mount each of the mirrors the same way
- run md5sum -C {saved_file} to check file content
If you get files which don't compare copy to copy you can see that the
issue is real.
[1] rather than explain to newbies why neither changes to atime nor any
journal activity doesn't make the file content change, I do it this way.
[2] MD5 is fine to detect file changes. You need sha1 or such only to
detect malicious changes with intent to hide the change. Because it uses
little CPU it's as good as any. Use sha256sum or similar if you doubt me.
Having had mismatches on raid-1 and not on raid-6 using the same three
drives, I question the "hardware error" theory of mismatch origin.
--
Bill Davidsen <davidsen@xxxxxxx>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein
--
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
