Methods to improve write operations to UnRAID

[Lev]

I updated the second post in this thread with how one possibility of parallel writes could be viable through how 'Allocation Method' modifications with an unprotected array (no parity).

 

If that idea has merit, or it's full of holes lets discuss. I ask you to suspend the question of parity protection for the moment. If the parallel writes can be debated and survives, then I have a method to propose that will close the parity gap that was left open. But it's worthless to post if the initial foundation of parallel writes is wrong, or someone can alter or improve upon it!

 

In other words, BRING ON THE OTHER IDEAS or all you CRITICS...  Fire your bullets, bring your alternative ideas, tell me how its wrong. If what I wrote needs a diagram, say so. I've thought about taking the time to show a block diagram but figured if it wasn't simple enough to show in text, then maybe it that was a sign it was too complex to be viable. I'd be happy to draw it.

 

If this thread simply goes idle, either because no one can find fault (so boring, must be something I missed!) or simply I'm the only one who cares about parallel writes (I get that! It's not as sexy as what we really desire) set your timers to poke me after some time on this thread. I'll post the theorem that will lead to the parity solution. IHMO the parity gap is easier to close than finding common ground of what I've presented thus far with parallel writes.

 

At the moment I distracted exploring this unsupported Areca path, but really I'm seeking in this thread is ideas and paths to a SUPPORTABLE method that Tom and team can debate internally amoungst themselves. In the meantime they can observe and chuckle, as I'm sure we may cover some ground and ideas they already have. If you have a idea post it! A lot of great thinkers on this forum and unRAID has more flexiblity than it had where I started at in v4 that makes many more things possible.

[Lev]

Parallel Writes w/ Parity Protection has a working theory now on how to bring it to a prototype level for further research.

 

This is a continuation of this diary of research, read the previous posts as they layer towards a building of understanding.

 

As documented, and communicated poorly in my own writing, the previous posts lay the basis of the theory in which parallel writes to the array can be achieved by new 'Allocation Method'. No parity disk. This new 'Allocation Method' type is but a simply twist on the current ones, it just needs to ensure, or allow for, a different disk to be selected on each write operation to a given share. That enables parity writes to be possible, and how far it can scale in parallel is own constrained by the number of disks within that share, the allocation method will scale to N disks within a share.If you have 5 disks in share, and create 5 write operations to that share, then it will parallel write across all 5 disks at full speed.

 

 

 

 

 

 

 

 

[Lev]

Adding Parity protection to this theory is possible, but is constrained by parity disks to two write operations in parallel.

 

First you must imagine an array where a new parity type is possible. Where dual parity disks do not act as they do today. Rather Parity Disk 1 is for 'Odd Number' disks in the array, Parity Disk 2 is for 'Even Number' disks in the array. 

 

In this scenario, with dual parity where it is split odd/even disks, this would allow for parallel writes to two disks, if they are odd and even in number, in the same share, and two write operations are requested then they would happen in parallel to unique odd/even disks in that share, and parity 1 and parity 2. 

 

Example: User share 'Media' has disks 1-8 as part of the share. Parity disk 1 protects disk 1,3,5,7. Parity Disk 2 protects disk 2,4,6,8. When the first write operation occurs, it uses a traditional 'Allocation Method' as selected (High Water, Fill, doesn't matter really) , assume it's an 'odd numbered disk' it picks, disk 1. When the second write operation occurs while the first is still in progress 'Allocation Method' selected the 2nd best choice of the opposite numbering, in this case a 'even number disk', it picks disk 2.

 

That may be a corner case with that many limitations but it is simply to demonstrate a theory in which there is possibility. Furthermore in this example this array would take dual parity from protection all disks, to segregating the parity to one parity disk for odd numbered disks, the second parity for even numbered disks. Maybe that is a acceptable use case given certain use scenarios.

 

Thoughts?

 

 

 

[SSD]

interesting ideas, @Lev. I like the thought that all drives that meet the allocation method criteria could share in taking new writes. But, due to split level, the universe could still often be limited to a single disk. 

 

The odd/even parity groups is also a nice idea. Wouldn't even have to be odd/even, it could be user selected. This has an added advantage of limiting the number of disks protected by a parity disk in large arrays. I like it better than dual parity. If this were implanted, it could allow multiple parity groups in the same array, a relatively common enhancement request.

 

I will say, not to take anything away from your very worthwhile analysis, but for many the current parity protection model and associated write speeds are "fast enough", and with turbo write for larger bulk transfers, that tools exist to overcome a large percentage of problematic write constrained use cases. But no one could argue that faster is better! 

[Lev]

6 hours ago, SSD said:

Wouldn't even have to be odd/even, it could be user selected.

 

@SSDYes totally agree. In fact what you suggested leads to thinking about it in two major ways that are related, UD & Array Drive Limit.

 

UnAssigned Devices:

It may lend ideas to how Unassigned Devices can be brought into UNRAID as I've seen @dlandon and @limetechmention was the plan. While there are many more factors I realize with UD being merged, so hate for this to sound like a over-simplification but there may be many areas of overlap with that idea.... disks that are selected by the user to not have parity protection would be the same in many respects to how UnAssigned Devices work today.

 

Array Drive Limit:

This may be stretching the limits of this idea but worth exploring... If a singe parity disk can be assigned to N array disks, then two independent parity drives could also be assigned, and could conceivably make it safer to go beyond 30 drive limit today, where N drives are protected by Parity 1, N drives are protected by Parity 2, and some drives have no parity at all.

 

 

[BRiT]

The Even/Odd drives with parity is just a specific case of supporting Multiple Arrays, with only 2 independent arrays configured.

[SSD]

6 hours ago, BRiT said:

The Even/Odd drives with parity is just a specific case of supporting Multiple Arrays, with only 2 independent arrays configured.

 

I agree they are similar. Sort of said that earlier ...

 

16 hours ago, SSD said:

The odd/even parity groups is also a nice idea. Wouldn't even have to be odd/even, it could be user selected. This has an added advantage of limiting the number of disks protected by a parity disk in large arrays. I like it better than dual parity. If this were implanted, it could allow multiple parity groups in the same array, a relatively common enhancement request.

 

But this is a little different. I have always thought that Multiple Arrays would operate independently - start and stop separately, with separate user shares. The idea here is that this is one "array", with one set of user shares that span both "parity sets". Perhaps they would even start and stop as a unit. And that unRAID would have awareness of what is in ParitySet1 and what is in ParitySet2 to make decisions about what disk to write to within a user share. In essence instead of dual parity as it is now, with 2 disks protecting all drives, you now have an array with 2 parity disks, each one protecting only half as many disks.

 

In this model, if two disks in the same set failed, you'd not be able to recover. 

 

But in the 2 parityset model, if one disk fail and corrupted parity on parityset1 as it died, and another disk on parityset2 died separately, you would lose the contents of only one of the two disks.

 

So which is better? Not sure. But something in me would rather have 2 15 drive parity sets each protected by a single parity drive, forming a single 30 drive "array", than a 30 drive parity set protected by dual parity. Just a gut feeling - will have to think about it more to see if it is a rational preference.

[Lev]

On 8/25/2017 at 6:43 PM, Lev said:

 

 

 

Added screenshot showing realized I/O gains from two file transfers in parallel to two different shares (ShareA, ShareB) that overlap all the same disks, when the second file transfer copy is started to ShareB, the disk that is already in use by the first file transfer for ShareA is excluded as a disk for ShareB.