I understand that the cache drives are currently used with a mover script. 

 

What if we did something like this instead?

1. Files gets moved to cache drive (which is fast, preferrably SSD drive, should be twice or three times as fast as to one of the drives in the array, if they are spin disks)

2. First file lands on Cache (SSD) drive, and Unraid moves the file to one of the drives in the array (while the second file is landing on the SSD drive).

3. The second file lands on the SSD drive, and Unraid moves this to one of the other drives, which is currently not active.

 

This repeats, untill Unraid is moving one file to each drive in the array, reaching the speed of the Cache drive. 

 

I understand that you would be moving files to and from the Cache drive at quite the rapid speed, and that this might be a problem for the Cache drive (especially if it's a spin disk drive) 

 

An alternative to running this at the same time, is to wait untill there is no operation on the Cache drive, and then move it to the spin drives, one file to each drive, for increased speed.

 

The reduced time the data would be on the cache disk, would be a security improvement, and the idea of writing to all drives, at the same time, from the cache drive, seems to me like quite the boost in performance. - Even if it did not happen at the exact same time as the transfer is happening to the cache drive.

 

The whole idea is to spread the load of the file transfers to more disks. I suppose this could be done with the Cache drives too. Load a file into the memory of Unraid, then save it on one of the Cache drives, the next file, from memory to the next Cache drive and so on. This would increase the write performance of Unraid quite a lot i would imagine. You could configure how much data you'd want Unraid to keep in memory for incoming filetransfers.

Edited December 27, 20196 yr by Bjørn Øyvind Halvorsen

1 hour ago, Bjørn Øyvind Halvorsen said:

The whole idea is to spread the load of the file transfers to more disks.

Unfortunately that won't work, and is even worse than you would imagine, because EVERY write to a data drive generates a write on the parity disk(s).

So, if sector1 on disk1 gets a write, and sector4 on disk2 gets a write, you have to wait for the parity to move back and forth between sector1 and 4 for each chunk written, so the write time for both transfers is much worse than a single transfer done one disk at a time. Each disk that you add as a target slows down all the transfers.

Hmm.. I hear you. 

 

It is possible to have two parity disks tho. Are they copies of each other, or half & half, that is; If there are four disks in the array, and two disks as parity, would two disks have one parity each, or would all four disks have the same two parities?

 

If one could set up the parities, one to each half of the array, you could at least double the write speed? or no?

If you have 2 Parity disks, they are not copies of one another as each one stores data to a different calculation / algorithm (mathematical formula used for parity determination).

I see.. So still across all drives then. 

 

This suggestion went from something to benefit all, to maybe a few to now, maybe just me and especially interested, so here we go. 

 

Would using hybrid disks/SSD's (one part ssd one part spin disk) as parity drives increase speed of the array drastically? Since this would likely not care where it writes to in the spinner part of the disk.. 

Edited December 28, 20196 yr by Bjørn Øyvind Halvorsen