Neil Brown wrote:
On Tuesday March 6, [EMAIL PROTECTED] wrote:
>
Though it is less likely, a regular filesystem could still (I think)
genuinely write different data to difference devices in a raid1/10.
So relying on mismatch_cnt for early problem detection probably isn't
really workable.
And I think that if a drive is returning bad data without signalling
an error, then you are very much into the 'late' side of problem
detection.
I agree with the later, but my concern is not that much with the cause,
but with the effect. From past discussion on the list I gather that no
special effort is made to determine which chunk to take as 'valid', even
though more than 2 logically identical chunks might be present
(raid1/10). And you also seem to think that the DMA syndrome might even
apply to plain fast-changing filesystems, left alone something with
multiple layers (fs on lvm on raid).
So here is my question: how (theoretically) safe it is to use a raid1/10
array for something very disk intensive, e.g. a mail spool? How likely
it is that the effect you described above will creep different blocks
onto disks, and subsequently will return the wrong data to the kernel?
Should I look into raid5/6 for this kind of activity, in case both
uptime and data integrity are my number one priorities, and I am willing
to sacrifice performance?
Thank you
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html