Re: Raid6 array crashed-- 4-disk failure...(?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22:57, Maarten wrote:

> apoc ~ # mdadm --assemble --force /dev/md5  /dev/sd[fhijkl]1
> mdadm: forcing event count in /dev/sdl1(0) from 1057343 upto 1057345
> mdadm: forcing event count in /dev/sdj1(1) from 1057343 upto 1057345
> mdadm: forcing event count in /dev/sdf1(3) from 1057343 upto 1057345
> mdadm: forcing event count in /dev/sdi1(5) from 1057343 upto 1057345
> mdadm: /dev/md5 has been started with 6 drives (out of 7).

So four of the six disks were not uptodate. As Neil said, the
difference might just be the sb updates, so I'd guess the array
is fine.

> But: The array did not resync. I think this may be correct but my 
> understanding of raid-6 is still a bit flaky. It is degraded, but not 
> fully degraded, that would mean two drives missing as it is raid-6. So 
> there is indeed parity information now.

Yes, there is parity information. Raid6 uses two parities, freqently
called P and Q, where P is the ordinary xor parity that is also used
in raid5. So each 6-tuple of corresponding disk blocks has exactly
one of the following possible contents:

	D, D, D, D, D, P (Q is missing)
	D, D, D, D, D, Q (P is missing)
	D, D, D, D, P, Q (one of the D's is missing)

Only in the last case, one of the five data blocks is missing. In
this case the raid code uses the P parity to compute the contents of
the missing data block, which is cheap.

IOW, you're as safe as with raid5 ATM. However, there are other reasons
for not running a degraded raid6 array for longer than absolutely
necessary. One of them being that writes to a degraded raid6 array
are significantly slower.

Before adding the seventh disk you might want to check the parities
using mdadm --update=resync. From the mdadm man page:

	The resync option will cause the array to be marked dirty
	meaning that any redundancy in the array (e.g. parity for
	raid5, copies for raid1) may be incorrect.  This will cause
	the raid system to perform a "resync" pass to make sure that
	all redundant information is correct.

I wonder why raid6 isn't mentioned there. Neil, are there any reasons
for this?

Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux