<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16441" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=109423614-06062007>This is an interesting idea. You would still have
the vulnerability of a stripeset with "A" and "B" where a failure of a single
disk would cause the loss of data from two stripesets. Not sure I
would want that. If your concerned about utilizing all the drive space on
disk drives with different sizes you may be SOL on that unless you use a
SAN disk virtualization methodology.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=109423614-06062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=109423614-06062007>As for figuring out the second parity calculation on
RAID 6, what the manufacturers are realizing is that they don't necessarily have
to have a different parity algorithm to calculate the second parity.
Simply putting the same XOR parity data on two separate disks will provide the
same RAID 6 functionality as having a second parity calculation with lower
overhead on controllers. The old KISS methodology is coming back into
play. I think you will see more and more of the manufacturers going this
route.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=109423614-06062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=109423614-06062007>Phil</SPAN></FONT></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
Alternatively, make it two separate 4-drive RAID 5 arrays.<BR><BR>To be
brutally honest, I tried to read the technical description of how the second
parity is calculated, but I can't make sense of it. <BR><BR>In our 8-drive
scenario, we have a stripe of 6 data blocks, a parity block which is the xor
of the 6 data, and some funkified thing I can't wrap my brain around, that
somehow allows us to reconstruct any two failed data blocks, so long as we
have the other four plus the two parity blocks. And I just don't get how
that can work. For the sake of argument, I'll assume it can somehow;
it's got to be a hell of a lot more complicated than XOR. <BR><BR>I might even
recommend the 8 drives be set up as a 7-drive RAID 5 with the 8th drive in the
bullpen waiting to be thrown in as a hot spare. When a drive fails, the relief
drive would be brought up to speed with the others automagically, and you'd
get a text message on your cell phone telling you that a drive had failed in
the array. <BR><BR>[Tangent alert]<BR><BR>Looking at the Drobo (<A
href="http://www.drobo.com/">http://www.drobo.com/</A>) has me thinking about
how I'd design a software RAID solution to automatically use the space the
best way, regardless of how many and how large the drives are. <BR><BR>Let's
say we have a cage that can handle up to 8 hot-pluggable drives. A
single drive is trivial; it's just a disk. With two or more drives, the
system would allocate all the space on the smaller drives to mirror the same
amount of space on the larger one in a RAID-1 configuration: <BR><BR>D1
AAAAAAA<BR>D2 AAAAAAABB<BR>D3 AAAAAAABB<BR>...<BR>DN AAAAAAABBZZZZZ<BR><BR>The
areas marked A would be mirrored across all drives. Reads could be done
in parallel, fetching different sectors from each drive to get the benefit of
striping. The areas marked B would be mirrored across the drives on
which they exist, and Z would not be mirrorred at all, so it would not be
available except for applications that have specifically asked for the
unmirrored filesystem (the box would export several filesystems to the
network, each with different redundancy priority; you could use non-redundant
space for work files that could be reconstructed if a drive failed.).
<BR><BR>Now, once all of the A and B areas are nearly full, the system starts
converting them, a bit at a time, into RAID 5:<BR><BR>D1 aAAAAAA<BR>D2
aAAAAAABB<BR>D3 aAAAAAABB<BR>...<BR>DN aAAAAAABBZZZZZ<BR><BR>D1 aaAAAAA<BR>D2
aaAAAAABB<BR>D3 aaAAAAABB<BR>...<BR>DN aaAAAAABBZZZZZ<BR>. . .<BR>D1
aaaaaaa<BR>D2 aaaaaaabb<BR>D3 aaaaaaabb<BR>...<BR>DN aaaaaaabbZZZZZ<BR><BR>At
this point, we've got all the drives doing as much RAID-5 as they can, then
another chunk of RAID-5 that's missing the smallest drive, etc., until we get
to the largest drive that still has that damned unmirrored section. This
is as big as it can get without losing redundancy. We might allow the
unmirrored area to grow downward and take up some of the space toward the
right, since that's the area where parity is the highest percentage of data.
<BR><BR>But somewhere along the line, we throw another drive into the cage,
and the system would automatically mirror the RAID-1 zone, and the RAID-5 gets
reconfigured to use the new drive, expanding the space available in the
process. <BR><BR>To do this right would probably include rewriting LVM
code, but it ought to be possible in userspace as a proof of
concept.<BR></DIV></BLOCKQUOTE></BODY></HTML>