UnRaid operates on the premise that by adding a parity drive, you can calculate a parity across all of the drives, add whatever is required (0 or 1) stored on the parity drive to make the resulting parity always zero, and you have nirvana.  Lose a drive and you can "get it back" by running a calc of what remains and whatever it takes to make the parity zero is what the corresponding bit on the missing drive must have been.  Simple right?

 

It seems that we could do a couple of things to keep the speed up, and incidentally possibly increase reliability.  By "we" I mean Tom of course. 

 

1) The drives should be "stacked" (end to end) or "folded" for parity calcs.

 

What I am hearing is that if you have different sized drives, you must have the parity drive be as big as or bigger than the biggest data drive.  Makes sense, however the rub comes from smaller drives.  If I have a 2 terabyte parity drive and a 500 g data drive, then the parity engine uses the actual data of the 500g drive for calcing the parity, and it uses zeros for the "missing" 1.5 tb. 

 

That's cool and it works.

 

However what happens if you a 2 TB parity drive and you have 8x 500 g drives.  Suddenly you are calcing parity across 9 drives - the 2 tb parity drive and the 8 500g drives.  And you are "calcing" the missing 1.5 tb for all 8 of those drives using zeros for all of that missing data.

 

Would it be possible to "fold" 4x 500g drives into one 2 tb drive, just for the purpose of parity calcs?  We all understand raid zero where we place 4x 500g drives end to end to form a 2 tb drive.  Imagine that 2 tb raid 0 drive created from 4x 500g drives.  When you run your calcs for parity, suddenly instead of reading all 8 drives to calc parity, you are reading just the drive for that "slice" of the 2 TB "virtual" drive.  Now you are reading only two of the 500g drives to calculate parity for any slice of data. 

 

Consider this.  If I have a (real) 2 tb parity drive, and I have "folded" 4x 500g drives and used these 4 drives to emulate 2 tb (for parity calcing sake), I could lose ANY OF OR EVEN OR ALL FOUR 500G data drives and still be able to recover all of the data. 

 

2) We should have "sets" of drives with a parity drive per set.

 

Alternatively we could have "sets" of drives grouped by size.  Imagine my actual scenario.  I have 2x 1.5 TB drives, 4X 1 tb drives, 9x 600gb drives and 1x 500gb drives.

 

It would be possible (and faster write speeds) to take one 1.5tb drive as one of my parity drives and use it to calc parity for the other 1.5tb and 4x 1 tb drives.  I could then take one of my 600g drives and use it as a parity drive for my remaining 8x 600g drives and the 500g drive.  Now I have two UnRaid arrays, each at least somewhat faster writing.  I would give up one of the smaller drives (lose 600 megs of storage), but the write speeds to the "larger" array (larger disk drives) would be significantly faster since the parity calc would only have to read 5x drives instead of 15x drives.

 

In a situation like mine where I have a ton of older / smaller but still useful drives, I would be willing to give up some of the space to get the write speed back up.  Additionally, w could now lose one drive in each "set" and still recover all of our data.

 

So both of these scenarios (folding and dividing) would also under some circumstances increase the reliability of the storage solution.

 

Bonus thought (outside of my allotted two per week)

 

When a drive fails, (assuming available free space) it should not be necessary to replace the disk, the data could be recovered to available free space and the parity recalculated.

 

OK, it is Sunday and I have already used up all of my thoughts for the week. :'(

I also had a thought long ago for a way to reduce parity calculation time:

 

http://lime-technology.com/forum/index.php?topic=5870.msg55472#msg55472

 

I think it was Brit who pointed out the flaw in my thinking, which also applies to your idea. What about disk expansion?

 

If your parity calculations are not constrained by port speed (eg. all drives on PCI bus). Then parity check will actually be slower. This is because the time to calculate a 128k strip of parity is limited by the slowest drive. If all of your eight 500G. drives are the same make and model, reading that strip of data is a stochastic process with an associated mean and variance. For each 128k stripe each drive has an equal probability of being the slowest drive and on average about 1.5 standard deviations away from the mean (assuming normal distribution of read times). Adding a ninth 500G drive identical to the last eight will only increase parity check time a percent or two. After the 500G drives are finished the parity drive can be written at full speed instead of being constrained by "stacked" 500G drives.

OK, it is Sunday and I have already used up all of my thoughts for the week. :'(

 

 

All sounds very reasonable and doable, JBOD and multiple RAID in a system, now a very realistic question, "How much you want to pay for the solutions?".  

I'll get back to you on "how much to pay".  I have used up all my thoughts for the week.

I really like the stacking disks to make a larger parity idea.  One of the problems, IMO, with upgrading to a new larger disks is that you have to buy 2 of the larger disks to get any benefit.  For example, if you wanted to buy a 3T drive in a machine that has a 2T parity, the only way you could use it is as parity - yielding only 2T of additional space.  Given that the 3T drive is expensive, you'd be more likely to just buy another 2T and get the same benefit.  So you'd need to buy 2 3T drives to get the benefit.  But if you could "stack" parity disks, you could buy one of the big boys, add a much less expensive disk to upsize parity, and you'd be able to use the 3T drive without buying 2.

 

But the stacked data drive concept has only one marginal at best benefit, but has a huge issue:

 

1 - (BENEFIT) You may see a speedup in parity builds, parity checks, and rebuild speed.  Pretty subtle though, as the drives run in parallel in these operations and combining may not have a dramatic impact in speed.  And they are infrequent - having no day-to-day benefit.

 

2 - (NO BENEFIT) It might appear at first that stacking could speed up writes.  unRAID already optimizes writes as much as it can, so therefore this stacking has no impact on writes.  In fact, unRAID will have to do some additional calculations to determine which sectors to read on which disks that could slow things down.  

 

FYI, here is how unRAID does a write, and why this means 2 reads and 2 writes for every logical write:

 

When unraid wants to write a block, it reads the block it is about to overwrite (from the data disk) and the corresponding block from parity.

 

Let's take some bits as an example (top is parity and bottom is data):

 

p 1 0 1 1 0 1 1 1

d 0 1 1 1 1 0 1 0

 

So say that we want to write these new data bits overwriting the data bits above:

 

d 1 1 0 1 0 1 1 0

 

unRAID can figure out that parity needs to maintain the same overall parity between the new data / new parity as it did with the old data / old parity.  So the first bit must stay odd, the second bit must stay odd, the third bit must stay even, etc.

 

unRAID can compute that new parity without reading all of the disks:

 

p 0 0 0 1 1 0 1 1

 

3 - (HUGE ISSUE) The biggest issue has to do with upgrades / rebuilds.  Let's say you wanted to upsize a 500G drive that is part of a "stack".  It will no longer be able to be in the stack, so will leave a hole that unRAID will need to manage and remember (okay, Tom can figure out that one).  But what about rebuilding the disk.  The 500G's drive may have been stacked on top of a 250G drive.  So its not just a matter of rebuilding data onto the new disk, parity is also being affected and will have to be updated.  And if power goes out and you need to begin again, you're out of luck.  Overcoming these challenges would be hugely difficult.

 

So - stacking could be good for parity, but not for data.  That's my conclusion anyway.

 

Might be interested in reading here

I like the Bonus thought in the OP.

 

I like the Bonus thought in the OP.

 

Forgot about that one.

 

Bonus thought (outside of my allotted two per week)

 

When a drive fails, (assuming available free space) it should not be necessary to replace the disk, the data could be recovered to available free space and the parity recalculated.

 

There was some discussion of allowing a warm spare to be loaded in the machine, and configured so that if a drive ever failed that unRAID would automatically use the spare to rebuild the failed disk.  Similar.  But this idea of copying data onto empty space on the array is a bit different, and seems like an idea that many users would like.

 

My personal sense is that if a drive fails, I want unRAID to do as little as possible and leave it to me (the human) to figure out what to do to recover.  Say, for example, that the disk failed becuase the server was overheating (maybe your HVAC failed or a fan failed in a backplane.)  Or your PSU was failing and took the drive offline.  Or a controller was failing.  Lots of things can cause something that looks like a failed drive, and depending on what it is, you might not want spin up every drive in the array and start lots of I/O.

 

I would like an option that if a drive fails, that unRAID would run WeeboTech's powerdown script.  It captures a syslog to the flashdisk, stops the array, and shuts down the server.  I figure that's the safest thing it can do, and allow me to come back at a later time and try to figure out what happened.

 

But this is just my personal perspective.  Others would like a more "self healing" array.  All are valid. 

 

If Tom creates subscribable events in 5.0 (as was discussed many times), then people could configure a variety of behaviors and users can configure the one that works for them.  See here..  (Its disappointing that Tom put that entire thread in the Bilge).

I'll get back to you on "how much to pay".  I have used up all my thoughts for the week.

 

 

"stacked" disk or rather "concated disk" as we called it in old days is used to join smaller disks together and presenting to software/users as a linear space. Back to when disk size was much smaller, software such as Oracle database had been requesting large amount of disk space that no single physical disk can do it. That is to say the main purpose of concatenated multiple disks together as one is for large space instead of I/O speed, although user might gain speed if underline hardware support asynchronize/simultaneous I/O such as the SCSI connect-reconnect functions. Of course later on peoples think JBOD (Just Bunch Of Disk) is a better name than simple-and-straight “concated disk”, this is not what we need to find out why, nowadays you just need to have some fancy names such as Yahoo, facebook, Java ……etc that no one really knows what do that meant or do. 

 

A RAID could operate in virtual level instead of in physical that is each member of a RAID is a virtual disk, similar design a virtual disk could be on top of multiple physical RAID and representing a linear space that is actually the preferred model large database will use, because database software only needs to know a huge available disk space and have system level software to take care of all those detail both space issue as well as protection issue.

 

To restore data in failed disk to available space is not an issue for data restoration as long as there is enough available space. However this

will be an disaster for user because after restoration, user will have difficult time to keep tracking of where are all those regenerated data. To illustrate how this is going to happen, here is an example, Let’s say we have a RAID with 3 data disks (A,B,C) + parity disk and we have 3 user shares (S1, S2, S3) each of them use one disk, that is S1(disk A), S2(disk B), S3 (disk C). let’s say now disk C had failed and without replacing disk C, system had regenerated data in disk C over disk A and B. Once data re-generation had finished where is the data for share S3? You can expand this example to RAID with 10 disks or 15 disks then you get some idea what might happen. Of course, this is not an issue if this data restoration is driven from user, in this design, this will rather be a data migration than data restoration that is user specify which disk that which piece of regenerated data will go to and once all data had been migrated out of failed disk, either regenerate parity of parity will be updated through whole migration process.

 

So with all those complexity, how much we are willing to pay? 

 

 

So with all those complexity, how much we are willing to pay? 

 

It could be even more fun (and expensive).  Suppose we fold a pair of 1 tb disks into a 2 tb virtual disk and use that as the parity disk. 

 

1) Now we have two party disks, either of which could fail and still be recover from.

2) We could (potentially) double the speed of parity checks and initialization etc. (assuming parallelization / threading of course)

 

So, folded parity and folded data disks...

 

The answer to your question of course is this is never going to happen within Unraid so the question (and entire discussion) is irrelevant. 

 

Though fun to contemplate of course.