RAID6? (was Re: Anyone Actually Using Virtual Linux Servers?)

[Daniel Feenberg]

On Tue, 11 Sep 2007, Jarod Wilson wrote:

> On Tuesday 11 September 2007 01:39:36 pm Jack Coats wrote:
>> Raid6 sounds like a reasonable upgrade from Raid5
>>
>> But as I have seen deomonstrated many times, no RAID level is better
>> than good, tested, verified, backups to another medium in case of a
>> 'worst case scenario'.
>
> I don't argue against that. I have backups, but I'd rather not have to
> use 'em, and RAID6 over RAID5 lessens the chance I'd have to.

The only problem I am aware of with RAID5 in the Linux "md" driver is that 
a drive is marked failed on the first bad sector encountered, and that 
once marked bad, the drive can not be consulted during rebuild. So if a 
single sector is unreadable, the drive is replaced and rebuilding begins, 
it continues only untill the first bad sector on any of the remaining 
drives is encountered, at which time there are two failed drives and 
reconstruction ceases. This is true even though the defect on the second 
drive would have been invisible if the sector had ever been written to, as 
the sector would have been remapped transparently.

Isolated bad sectors are not that unusual, especially on unoccupied 
sectors which may never have been written to in the life of the drive. 
Rebuilding is likely to trigger bad sector mapping on such sectors, since 
it is not file based. So an "md" based RAID5 is reliable in the sense that 
you can copy all the FILES off it, but the in-place reconstruction is not 
likely to succeed.

I have no personal experience with RAID[06] and do not know if similar 
problems arise, but I can't see why they would not.

As far as I am aware, this defect is not universal among RAID 
implementations, although for example on the 3ware controller it is the 
default with a setup option to continue on error during rebuild.

Hostility to RAID5 is widespread, but much of it is based on 
misinformation, or from the denial of any possible heterogeneity among 
users. For example, the claim that writes are slow because all sectors in 
a parity group must be read before any are written is significant only for 
random writes. In the case of sequential writes, all the sectors in the 
group will be written, so none of them have to be read, and the only 
overhead is writing parity. Some workloads (such as our statistical 
processing of large datasets) are almost entirely sequential.

In the case of the dramatic anti-RAID5 webpage mentioned before in this 
thread (I won't repeat the link), the worry that RAID5 doesn't parity 
check is overwrought - none of the RAID types parity check on read unless 
necessary to recover a bad sector. However, the drives themselves include 
extensive parity checking, so that there is generally thought to be little 
need to consult the parity drive on reads. This may be optimistic, but it 
isn't unique to RAID5.

Please see http://www.nber.org/sys-admin/linux-nas-raid.html for more 
information.

Daniel Feenberg

>
> -- 
> Jarod Wilson
> jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.