Re: chunks/sectors/blocks/stripes ??

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

 



On 04/08/18 17:10, donotcare@xxxxxxxxxxx wrote:
> Lastly, is the raid6check program (from  mdadm-4.0) considered a safe/reliable way to repair mismatches on raid6 arrays?

It's the ONLY way to do a guaranteed recovery from a mismatch. This is a
historic thing ...

On raid 5, if you have a mismatch, you can NOT recover - you have one
extra bit of info namely parity, but two unknowns the faulty drive and
the lost data. So "repair" on a raid 5 simply assumes that the parity is
at fault - which to be honest is the usual case - and recalculates and
rewrites it. If sods law says it's actually a data block that's dud,
sorry your data is gone.

Because of this, "repair" assumes the same is true for a raid 6 mismatch
- it recalculates and and rewrites the parity. And the chances are this
is the correct thing to do.

But it isn't always the correct thing to do. What raid6check does is it
actually checks - because it has two extra bits of info, it can work out
two unknowns namely the dud drive and what should be on it.

Don't expect the current situation to change, because the devs say -
quite reasonably - that ANY attempt to fix your drives without knowing
why they got corrupted is seriously hazardous to your data, and once you
know what went wrong you'll know how to fix it.

Cheers,
Wol
--
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



[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