Performance Difference With/Without Cache Drive


semicycle

Recommended Posts

I'm sure this ahs been discussed, but didn't find exactly what I was looking for...

 

Could someone please post their experiences using and not using a cache drive?  Benchmarks, throughput comparisons and any noted differences with multiple users writing/reading from the array would be great.  If the thread already exsists, could you point me there?

Link to comment

unRAID has fast read performance but slow write performance.  The reason for the slow write is that for each write operation, it has to READ the source drive, read the parity drive, write the source drive, then write the parity drive.  4 I/Os for each write.  It has to do this to maintain parity.

 

The cache drive is a NON-array disk that unRAID wil use to store data temporarily.  Through a little magic it looks like it is on your array using user shares, but it is not protected.  In the middle of the night a "mover" script runs that takes stuff off the cache drive and moves it to an array disk.  This move requires the 4 I/Os per write and is slow.  But who cares - it happens in the middle of the night.  Writes to the cache disk are fast (1 I/O per write and not 4).

 

I get about 3x times the write performance to a cache disk vs to an array disk (about 14 MB/sec writing to the unRAID array, about 45 to a cache disk).  But it is not really a true comparison, becuase after files are written to the cache, they still have to get written to the array.  So if you were trying to fill your array, the cache drive would actually slow you down.  But for most people, being able to finish copying files from their Windows workstation quicker is the most important thing.

 

Hope this helps.

Link to comment

 

I get about 3x times the write performance to a cache disk vs to an array disk (about 14 MB/sec writing to the unRAID array, about 45 to a cache disk). 

 

That's the type of info I was looking for.  As I continue waiting on my parts adn reading more posts it seems like it will be a good idea to intially copy everything over witih parity off, then enable it afterwards.  I hope that make the transfering of 2.5TB of data.

Link to comment

 

I get about 3x times the write performance to a cache disk vs to an array disk (about 14 MB/sec writing to the unRAID array, about 45 to a cache disk). 

 

That's the type of info I was looking for.  As I continue waiting on my parts adn reading more posts it seems like it will be a good idea to intially copy everything over witih parity off, then enable it afterwards.  I hope that make the transfering of 2.5TB of data.

You are absolutely correct.  If you do not assign the parity drive initially, it will greatly speed your initial migration of data from your other PCs.

 

You should be aware that it carries some risk, in that the data on the unRAID array will not be protected from a disk failure until there is a parity drive in place and the first full parity calculation has been performed.  This is only a real issue if you start moving the drives from your existing PCs after their contents has been migrated, but before the parity drive configured.  If you do, the original contents will not be there if a disk failure were to occur in the unraid server.  (It is VERY common for drives to fail in their first few hours of operation, so if possible, install the drives and run for a few days before you erase the original files on your other PCs.)

 

Other than that, the "cache" drive needs to be only big enough to handle the files you would normally write to the array in a given day.  It is NOT useful when transferring 2.5 T of data... do not assign one... as already mentioned, data on it is NOT protected until its mover script is run (typically one per night) and the data written to the protected disks in the array.

 

Joe L.

 

 

Link to comment

Added to the FAQ (link back only), here.  Feel free to edit or expand.

 

It would be nice to see additional empirical reports as to performance with and without a Cache drive.

 

Edit:  (By the way, Semicycle, great work adding detail to the Hardware Compatibility page.)

 

Edit2:  The question below was also added to the FAQ (link back only), here.

Link to comment

How would unRAID behave if a cache drive were enabled and MORE data were copied during the day than the capacity of the cache drive could handle???

According to an old post by Tom, one of two things, depending on how the file is "created" by the program doing the copy.

 

Some programs create an initial file of 0 size, then incrementally append to it.  These would use the cache drive (as it has  space for the initial zero length file), then fill the file incrementally, using up space on the cache drive till it has no more, then fail the attempt to copy to the unRAID array when no more space on the cache drive was present.

 

Other programs create an initial file of the exact size needed, then fill it.  If the initial file fits on the cache drive, it has enough space, and no failure will occur.  If the initial file does NOT fit on the cache drive, it will instead be created on one of the data drives, and the copy will continue as if the cache drive were not present at all.  In other words, it will succeed, and it will not need to be moved later to the data drive as it already will have parity calculated.  Obviously, this will not have the speed benefit of the cache drive, as parity must be computed as the file is copied directly to the unRAID array data disk.

 

Joe L.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.