Greetings,

 

I just recently started moving my things to Unraid. But I'm having performance issues in writes.

 

My hardware:

Intel Q9550

Asus P5Q Pro

8GB DDR2 Ram

4 x 3TB Seagate NAS

1 x 3TB WD Red

1 x Samsung 850 Evo 120GB

 

Since Im moving from another system, 2 of the disks are holding the data and not in the array yet (the red and 1 of the seagates)

My current setup is: 1 Seagate Nas as parity, 2 x in normal array using XFS and the SSD as cache (using BTRFS as default).

 

I created a Smb share using all disks (currently 2 available) and I had 2 results:

With cache: 110MB/s sustained until the SSD gets full, basically maximazing my network link, a Gbit connection.

without cache: 30MB/s to 40MB/s max

 

The drives can handle +100MB/s each easily on this type of file copy (Movies and series) but for some reason when copying directly to the array, the speed is fairly low.

While doing Parity check the Parity drive (a Seagate NAS) does around 115 MB/s. Checking SMART everything is ok. The share isnt being used anywhere else, the server is brand new.

 

Any ideas what might be causing this slow speed?

 

Thanks,

Ralms.

Completely normal. Writing to the parity array is always slower since parity must also be calculated and written. There are 2 methods for parity writes. The normal way only requires parity and the drive to be written to spin. The turbo (reconstruct) way requires all disks in the array to spin. Normal and Turbo write are explained in more detail in the Turbo Write thread.

This is why the cache drive feature was created. Writes to any user share can be cached and then moved to the array at a later schedule time.

 

I don't care about write speed so I just use cache for dockers and VMs. This prevents apps like Plex which do frequent writes to their "working storage" from keeping array drives spun up.

Completely normal. Writing to the parity array is always slower since parity must also be calculated and written. There are 2 methods for parity writes. The normal way only requires parity and the drive to be written to spin. The turbo (reconstruct) way requires all disks in the array to spin. Normal and Turbo write are explained in more detail in the Turbo Write thread.

This is why the cache drive feature was created. Writes to any user share can be cached and then moved to the array at a later schedule time.

 

I don't care about write speed so I just use cache for dockers and VMs. This prevents apps like Plex which do frequent writes to their "working storage" from keeping array drives spun up.

 

Hello,

Thank you for the fast reply.

 

I didnt know about that Turbo Write option, I will try it later. My concern was mostly for now since I was copying 3TB of data and the first 2.5TB took around 30h to do.

Later I will use cache and not care, like I said in my first post, with cache I hit 110MB/s constantly.

 

But just wondering, having the drives spun up all the time isnt gona improve the drive life expectancy in the long run other than having multiple spun-down/spun-up?

My drives are always cool at around 28º to 30º so I was wondering if keeping all drives up all the time isnt gona just help.

 

Thanks,

Ralms.

But just wondering, having the drives spun up all the time isnt gona improve the drive life expectancy in the long run other than having multiple spun-down/spun-up?

My drives are always cool at around 28º to 30º so I was wondering if keeping all drives up all the time isnt gona just help.

 

If you don't care about power consumption most believe that it's much better for a disk to be always spinning instead of frequently spinning up/down.

Just an update.

 

You guys where right, I set the Disk settings -> "Tunable (md_write_method)" in "Reconstruct write", so Turbo, and I max the Gbit network instantly.

 

Thank you very much

 

Best Regards,

Ralms.