Cache does not affect write speeds

[geonerdist]

I have been heavily digging through the forum and the internet regarding my issue (or non-issue), I can only find information that basically says it is not working as it should. I am experiencing slower than expected write speeds from a wired connection. Read speeds saturate the gigabit network. I currently run 3 WD Reds (2 4TB and a 1TB as a cache). Other specs in my signature. Speeds writing to shares average about 85MB/s whether transferring a Windows 7 Home ISO to a share that has cache enabled or not. I attempted to use the Turbo Write plugin. YouTubers such as Spaceinvader1 and Mike Fury Tech lead me believe I should be seeing faster write speeds. Such as Mike Fury Tech's video comparing write speeds with and without cache enabled (my guess is he has an SSD instead of a mechanical drive). I'm still learning here! I do admit the current speeds are 8 times better than I saw with my WD MyBook Live. Just the mass of information out there has me thinking something is not quite right. Basically ti boils down to two questions:

 

1. Are these normal write speeds for using a mechanical 5400RPM drive as a cache?

2. I am thinking about setting up a cache pool using two SSDs, will this actually increase my write speeds? 

 

I have ran the disk speed test plug in and speeds are what I expected and similar to speeds reported by WD Red drives. I did some copy testing using this ISO this morning, near the end of the diagnostics attached which included turbo write enabled. Cheers!

tower-diagnostics-20170807-1135.zip

[itimpi]

Write speeds of 85MB/s seem very good for running without a cache drive.    Speeds around 40MB/s are more typical in such cases.   I note that you are running with only a single data drive and one parity drive and that is a special case where write speeds can be more than would be expected when you add additional data drives.   Since a Gigabit Network saturates at a bit over 100 MB/s a 5400 rpm cache drive can easily handle that.   You do not get significant speed boosts from a SSD in such cases - SSD becomes more important when running dockers or VMs which can be doing a lot of local file access by-passing the network.

[Frank1940]

Another factor.  The figures that @itimpi quoted are theoretical maximums!  Once you start real-world transfers, a number of other factors enter into the picture.  The first (and biggest) one is the size of the files involved.  Transfer of a single 20+GB file is much faster than 20+GB of 4MB files.  There is the file creation and disk space allocation time overhead plus all of the head movements to the proper track and rotational latency time to the proper sector times.  They are an insignificant percentage of the total time for a 20Gb file but that is not true for 4MB file.  ssd's will provide major advantages in reducing the mechanical times but the file allocation and creation overhead will still be there. 

 

I will make one more observation.  Some Dockers will keep a mechanical cache drive spun up most of the time!  So if you are concerned with either power consumption from this factor or have concerns that keeping the disk spun all of the time will reduce its life, go with an ssd right from the start.  (I didn't know about this at the time when I installed my cache drives and I now wish I had gone with the ssd because of the Docker issue.) 

[trurl]

Haven't looked at your diagnostics, but just thought I would add a few thoughts about speed. Your speeds seem fine to me. Do you really need much faster writes?

 

Caching writes can be a good tradeoff, but it is a tradeoff with pluses and minuses. Unless you have a redundant cache pool, cached data is unprotected until it is moved to the array. If you write a lot of data to cache, you can fill it up before it gets moved. And if you have mover scheduled frequently to take care of the volume, it can interfere with other writes since it is also reading/writing cache and the array. Etc.

 

Just some things to consider. I don't cache most of my user shares. Many of the writes to my array are unattended anyway, being scheduled downloads and backups.

 

[geonerdist]

Apologies all for the slow reply, I was just about to head out on vacation and thought I replied but did not. You all just confirmed what i thought, but I did learn something. So when only running with a single data and parity drive the speeds are best and slow down as more data drives are added to the array. Essentially when I add a second data drive, I will notice a speed difference between cached and non-cached shares. I was just confused that mine were showing the same exact speeds. Thanks again!

[trurl]

2 minutes ago, geonerdist said:

So when only running with a single data and parity drive the speeds are best and slow down as more data drives are added to the array.

Additional drives shouldn't affect write speed, whether doing turbo write or normal write, unless you have some sort of controller bottleneck.

 

With normal write, only the data drive written and parity are involved. WIth turbo write, all disks are involved, but they are accessed in parallel unless some sort of multiplexing is happening.

[Frank1940]

1 minute ago, trurl said:

Additional drives shouldn't affect write speed, whether doing turbo write or normal write, unless you have some sort of controller bottleneck.

This is only true if the drives have similar read/write speeds.  This is many times not true when someone has a fast modern high (data) density drives that are used for the initial build and the next one added is a recycled older low density drive with a slow spindle speed.  

[trurl]

47 minutes ago, Frank1940 said:

This is only true if the drives have similar read/write speeds.  This is many times not true when someone has a fast modern high (data) density drives that are used for the initial build and the next one added is a recycled older low density drive with a slow spindle speed.  

Speed of involved drives matters, of course. Number of drives doesn't unless the involved drives can't be accessed simultaneously.