I have come across an unusual RAID configuration type which differs
from any of the standard RAID 0/1/4/5 levels currently available in
the md driver, and has a couple of very useful properties (see below).
I think it would be useful to have this code included in the main
kernel, as it allows for some use cases that aren't well catered for
with the standard RAID levels. I was wondering what people's thoughts
on this might be?
The RAID type has been named "unRAID" by it's author, and is basically
similar to RAID 4 but without data being striped across the drives in
the array. In an n-drive array (where the drives need not have the
same capacity), n-1 of the drives appear as independent drives with
data written to them as with a single standalone drive, and the 1
remaining drive is a parity drive (this must be the largest capacity
drive), which stores the bitwise XOR of the data on the other n-1
drives (where the data being XORed is taken to be 0 if we're past the
end of that particular drive). Data recovery then works as per normal
RAID 4/5 in the case of the failure of any one of the drives in the
array.
The advantages of this are:
- Drives need not be of the same size as each other; the only
requirement is that the parity drive must be the largest drive in the
array. The available space of the array is the sum of the space of
all drives in the array, minus the size of the largest drive.
- Data protection is slightly better than with RAID 4/5 in that in the
event of multiple drive failures, only some data is lost (since the
data on any non-failed, non-parity drives is usable).
The disadvantages are:
- Performance:
- As there is no striping, on a non-degraded array the read
performance will be identical to that of a single drive setup, and the
write performance will be comparable or somewhat worse than that of a
single-drive setup.
- On a degraded arrays with many drives the read and write
performance could take further hits due to the PCI / PCI-E bus getting
saturated.
The company which has implemented this is "Lime technology" (website
here: http://www.lime-technology.com/); an overview of the technical
detail is given on their website here:
http://www.lime-technology.com/wordpress/?page_id=13. The changes
made to the Linux md driver to support this have been released under
the GPL by the author - I've attached these to this email.
Now I'm guessing that the reason this hasn't been implemented before
is that in most cases the points above mean that this is a worse
option than RAID 5, however there is a strong use case for this
system. For many home users who want data redundancy, the current
RAID levels are impractical because the user has many hard drives of
different sizes accumulated over the years. Even for new setups, it
is generally not cost-effective to buy multiple identical sized hard
drives, compared with incrementally adding storage of the capacity
which is at the best price per GB at the time. The fact that there is
a need for this type of flexibility is evidenced, for example, by
various forum threads such as for example this thread containing over
1500 posts in a specialized audio / video forum:
http://www.avsforum.com/avs-vb/showthread.php?t=573986, as well as the
active community in the forums on the Lime technology website.
Would there be interest in making this kind of addition to the md code?
PS: In case it wasn't clear, the attached code is simply the code the
author has released under GPL - it's intended just for reference, not
as proposed code for review.
<<attachment: unraid_code.zip>>
