On 09/01/17 04:40, Piergiorgio Sartor wrote:
On Fri, Dec 23, 2016 at 11:56:34AM +1100, Eyal Lebedinsky wrote:
From time to time I get non-zero mismatch_count in the weekly scrub. The way I handle
it is to run a check around the stripe (I have a background job printing the mismatch
count and /proc/mdstat regularly) which should report the same count.
I now drill into the fs to find which files use this area, deal with them and delete
the bad ones. I then run a repair on that small area.
I now found about raid6check which can actually tell me which disk holds the bad data.
This is something raid6 should be able to do assuming a single error.
Hoping it is one bad disk, the simple solution now is to recover the bad stripe on
that disk.
Will a 'repair' rewrite the bad disk or just create fresh P+Q which may just make the
bad data invisible to a 'check'? I recall this being the case in the past.
"repair" should fix the data which is assumed
You say "should", as in "it does today" or as in "need to change to do" this?
As I noted originally, the man pages says it does the simple thing - should the
man page be fixed?
to be wrong.
It should not simply correct P+Q, but really
find out which disk is not OK and fix it.
'man md' still says
For RAID5/RAID6 new parity blocks are written
I think RAID6 can do better.
TIA
--
Eyal Lebedinsky (eyal@xxxxxxxxxxxxxx)
--
Eyal Lebedinsky (eyal@xxxxxxxxxxxxxx)
--
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
