Do you use a cache device in your unRAID server?



Recommended Posts

  • 4 weeks later...
  • 2 weeks later...

No cache drive, as my hardware controller has a 512 MB ECC and battery protected cache working on all single disks for both reading and writing.

So I have additional slots free for more data drives.

 

The cache is big enough for small transfers and big transfers are cached considering the writing queue so that the write performance is between 35-45 MB/s which is quite good.

Though I would prefer that the parity would be build with using all drives but not only the current data drive and the parity drive - like that the performance would be a lot higher and cache drives wouldn't be needed anymore at all.

Link to comment

No cache drive, as my hardware controller has a 512 MB ECC and battery protected cache working on all single disks for both reading and writing.

So I have additional slots free for more data drives.

 

The cache is big enough for small transfers and big transfers are cached considering the writing queue so that the write performance is between 35-45 MB/s which is quite good.

Though I would prefer that the parity would be build with using all drives but not only the current data drive and the parity drive - like that the performance would be a lot higher and cache drives wouldn't be needed anymore at all.

Here
Link to comment

No cache drive, as my hardware controller has a 512 MB ECC and battery protected cache working on all single disks for both reading and writing.

So I have additional slots free for more data drives.

 

The cache is big enough for small transfers and big transfers are cached considering the writing queue so that the write performance is between 35-45 MB/s which is quite good.

Though I would prefer that the parity would be build with using all drives but not only the current data drive and the parity drive - like that the performance would be a lot higher and cache drives wouldn't be needed anymore at all.

 

I don't believe you understand what unRAID is all about.  What you are talking about is traditional striped RAID, with both its higher performance advantages and lower data security.  If all you want is higher performance, then a traditional RAID 5 or 6 controller is all you need.  unRAID could have gone that way a long time ago, but it would probably have died a long time ago too, as who needs another RAID 5 controller, there are so many choices already.  unRAID went a different route, as an un-striped variation of RAID 4, with each disk an independent file system, MUCH safer - if a disk has trouble then most of data usually still safe, not all lost.  If multiple drives in trouble, then all lost in RAID 5, but in unRAID usually only a little loss, rarely entire drives, and NEVER the entire array.  Plus, there's the power savings, as individual drives can spin down.  The entire array can stay down for long periods, then only one drive up for playback.  Many unRAID users save significant money on their power bill that way.  Higher performance is completely unnecessary for media servers and backup servers, the primary usage for unRAID type arrays.  Data security and overall costs are more important.  Plus, there's the tremendous unRAID flexibility in designing and maintaining an array, with completely mismatched drives of all sizes and types and speeds, some on IDE connectors, some on SATA, more types in the future.  And any drive can be replaced and expanded (with a larger drive) while the array is live.

 

As you know, there are many kinds of caches, and the unRAID cache drive is not the same thing as a traditional cache drive.  It's used as a temporary holding place for direct writes to the array, so that array writes can be performed at maximum speed limited only by the network.  Then at chosen intervals, files are moved to parity protected storage on the unRAID array.  While cached, the actual location is hidden, the files appear in the shared storage as already part of the array.

Link to comment

...

Here

Thanks a lot!!! I am impressed! That is what I needed, I just didn't remeber what it was called... "Turbo write" - that's it!

 

@RobJ

I am fully aware of the features of unRAID that you told me of. That is why I am not(!) using my RAID controller for building a traditional RAID with it but only for having cache/battery protected single disks that are redirected to unRAID. Having the possibility to use "Turbo write" is all I wanted for higher writing performance, because the faster the data is on the parity protected unRAID, the better. (Yeah and we are of course not talking about backups! We are talking about redundancy in case of HDD failure. Backups are held on different machines simultaneously, but the faster they are synchronized between these machines and the unRAID, the better!)

 

The possibility to combine drives of different sizes (I do - having 14 drives of different sizes) and the possibility to expand the array "when needed" (with a 24 slot hardware raid controller having enough expansion slots) and all the other features you said, like one only looses data of the drives that crash (when two drives are gone simultaneously) but not the entire array, that is everything I appreciate.

 

The unRAID cache drive is of course something different than a RAID controller memory cache, but as I have that memory cache with battery protection, I am using that one. And when writing small files like with some hundred MB, they are transferred with gigabit speed to the memory cache and are written delayed to the parity protected disks.

Till now the parity drive needed to be rotated for reading and writing the new parity information - with turbo write, I can achive higher speeds in writing as I dont need to read and write anymore from the same disk but use the other disks for reading while writing. And like that, the data is written faster, the data is parity protected faster and the memory cache has higher throughput.

 

I don't see why it should not be a concern to write data faster to the parity protected array with turbo write? I don't need several hundreds of MB/s and I don't need the unflexible RAID5 with its dangerous striping - but having, I don't know, 60-70 MB/s writing speed instead of 40 MB/s means that my data is faster parity protected - and during the write the memory cache protects with its battery so that no data is lost in case of a sudden powerdown. I think that is quite reasonable, no?

Link to comment

Certainly is.  It's always hard to determine a users' experience level, and I got the impression from your post that you had little unRAID experience.  My apologies.

It was definitely my fault ;) As I am not a native english speaker, it seems I did not express myself very well. So nothing to apologize!

I never meant RAID5 when I said "I want to use all drives for parity writing" but I meant "Turbo Write" which uses "all drives for parity writing" - but in another context, not for striping but for reading the blocks needed for building parity over all drives. So it was indeed unclearly expressed by myself.

Link to comment

No.  I am using my array to store backups from 3 Windows workstations.

 

Case: Norco ITX-S4 (Mini-ITX)/Seasonic Power Supply

Motherboard:  Asus H87I-PLUS

CPU: Intel i3-4130T @ 2.90GHz

RAM: 4GB

Drives: Parity - HGST 4TB

        Data1 - Toshiba 3TB

        Data2 - WDC 2TB

        Data3 - Toshiba 4TB

Unraid 6.1.3

Link to comment
Guest
This topic is now closed to further replies.