It takes about 23 hours per check if I don't do anything to the array,
so it will be a while before I can get back to you with results. But
thanks for the quick response.
./Andrew
On 4/21/2011 8:14 AM, NeilBrown wrote:
On Thu, 21 Apr 2011 08:00:39 -0500 Andrew Falgout<andrew.falgout@xxxxxxxxx>
wrote:
I got an error last week from a new raid6 array about a mismatch_cnt. I
did some reading online, performed a repair action on the array,
performed a check action, and checked for the mismatch_cnt again. The
number was greatly reduced, but it was still there. According to mdadm,
everything appears to be working fine. All the drives are passing short
tests on smartctl.
What is mismatch_cnt really? Should I even be concerned about this?
Yes, you should be concerned.
mismatch_cnt is a count of sectors where the parity blocks don't match the
data blocks.
The code doesn't check every sector individually. For raid5/6 it checks 4K
at a time, so divide by 8, and that many 4K blocks are in doubt.
So something if going wrong somewhere.
I would run 'check' a few time and see if the number changes.
If it goes down at all, then it looks like you occasionally get bad reads
from a device.
If it only ever increases, then you are presumably getting bad writes
sometimes.
You could:
- stop the array
- run sha1sum on each member disk, several times.
- if any one disk has an unstable result - check cabling, or replace the disk
- if more than one disk has an unstable result, replace the controller maybe.
- if all results are stable it must be a write-only problem - much harder
to work with.
NeilBrown
The array is giving me 25-30MB/sec performance on an sshfs mount over
the network. With a local copy I can see speeds of 50 to 60MB/sec.
Thanks,
Andrew Falgout
--
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
