As much as I like the idea of a cache drive (as it will both improve write speed and also can be used as scratch space etc. without affecting the R/W speeds of the actual array), it does effectively waste a hard drive in terms of your maximum parity-protected storage. Cache drives generally don't need to be that big - I have a 250gb hard drive lying around that I'm going to use as my cache drive. So I'm curious as to why it needs to be an entire drive bay?

 

Would it be possible to alter the cache drive feature so that it is actually a cache partition instead, and the rest of the drive could be used to store parity-protected data as part of the array. For example, if I had a 2tb drive, I could partition the first 250GB to be the cache partition and then have the remaining 1.75TB as part of the parity-protected array.

 

I assume that this must be, theoretically speaking, possible. Don't get me wrong - I don't assume to understand exactly how unRAID is coded, but it must be possible to get the parity calculations to only take into account a certain range of bits on the drive rather than the drive as a whole. Clearly this would have a negative impact on the speed at which you can write to the parity protected data partition if the cache partition is being used, but a) that scenario won't happen all the time as generally writing to the parity protected partition would only happen when the cache drive is doing its daily copy to the array and b) it would still be significantly quicker to write to a cache partition than a realtime partity protected drive.

It could be possible in theory but it's not likely to work. unRAID basically puts a single partition on the whole drive. Then, it calculates parity for that whole partition. So, the cache partition would have to be the second partition.

 

The big problem I see is that unRAID would have to store and track the drive with the cache partition and have a way to handle upgrading or replacing the data drive while keeping the cache partition in place. Then, what happens to any data on the cache partition? So, it's just simpler to use a seperate drive.

 

I don't think it's unRAID's concern to have to maintain the cache partition, I would expect users to manually back the cache partition up as they would if they were upgrading or replacing an existing cache drive.

This would be possible... but I question if the time would be worth it.

 

This would probably add to the complexity of rebuilding a failed drive that also happened to be the "cache drive"

I don't think this is worth the effort.

It takes long enough for productive updates and changes to unRAID to be released.

 

This particular request would not be very productive.

There's little benefit, and probably more of a hindrance, by using part of the parity for the cache space.

When you go to move data from the cache drive to your parity protected array, this hybrid drive is going to be the busiest drive in the array.

In addition, consider the complexity of tracking which sectors belong to the parity and cache inside the unraid/md drivers.

The added code complexity will probably slow down the speed of the md driver.

 

Also in consideration is,  how useful would this be to the unRAID user base?

 

The closest we come to sharing parity and cache is the hyrbrid solution using a Silicon steelvine processor with a SAFE50, SAFE33 arrangement or ARC-1200 Raid Array card.

 

If the sole purpose is to save an internal bay or the cost of a single drive vs added code complexity and poorer performance I can't see it being worthwhile.

 

Speaking frankly,  this type of solution can be handled by throwing a little bit of money at a custom solution.