On 05/05/99 13:01:00 you wrote:
Short of a software error in calculating parity or a similar write problem, there probably isn't a way.
A variety of ways. Two immediately spring to mind:
1. The block with the error did not go bad until after data had been written to it, but before data was read from it. 2. The drive thought the data was written correctly but was incorrect. 3. The drive thought the data was read correctly but was incorrect.
I've usually seen parity inconsistencies as a result of an improper shutdown. However these are repaired immediately upon reboot.
I don't think it may have in fact rewritten a data block (I could be wrong). Rather, they read all the data, and the parity block was inconsistent with the data, so they rewrote the parity information. I'm not sure if there is any way to know for sure that the parity is actually correct and it is the data block that is wrong.
I think you're basically saying the same thing here; the problem could be in the data block, not the parity block. In any case, assuming it is parity then they can determine which block goes on that stripe.
(3) How can we (as end users) map the stripe number to disk blocks, and then further to the data and/or filesystem info (Inode) blocks.
I don't think there's any way without an expensive scan of various metadata files. However, it would be nice if every such disk message contained such information.
(4) Short of wacky how can we be really sure of our filesystem/data integrity?
No way, but if the filesystem is fine then wacky won't tell you if the data is corrupt either. If the block of zeroes got all flipped to ones, and the parity was rewritten to accomodate that, there's no way to know that it happened unless you happen to know the block should be otherwise in a given file.
Yep. The bottom line is - don't worry about it, as they are probably of no consequence. If you continue to get inconsistent parity, it could be a pointer to some other problem.
Bruce