I am using unRaid on a trial basis at the moment and the biggest hang up is the transfer speed. I've performed a search on the form and there are plenty of threads on the subject and I still cannot arrive at a solution. 

 

I have an N54L with 16Gb RAM and currently it is running a 3Tb Hitachi  Deskstar parity, a single Hitachi Deskstar 3Tb data drive and a Samsung Evo 850 250gb for cache. Previously running W2012 server with transfer speeds up to 110Mb/sec.

 

Initial sync was between 32-38Mb/sec.

Internal Transfer from Unassigned 2Tb WD Red to parity storage peaking at 50Mb/sec. My understanding is that with a cache drive this should be at 90Mb/sec especially as there are only two drives in the array (parity and data). The cache drive is doing didley squat apart from hold the apps/vms.

 

I have read about an N54L build with Cache enabled in the BIOS which yielded a decent throughput but I don't want to do that as I don't have a UPS.

 

I plan to add a second Hitachi 3Tb drive to array to increase storage to 6Tb total, run Plex server, and a few VMs (linux distro testing and one for VMS (CCTV, which will record to the unassigned 2Tb WD Red drive).

 

Screenshot attached of setup. I'm hoping that adding another drive does not half the speed again... I'm would like to test turbo/reconstruct write but I'm not sure how it works yet, ie. the risks involved. Am I expecting too much of my N54L?

 

Would ESXI with DSM be a better option?

 

Am I unreasonable 

Caching only happens when writing to user shares that have been set to cache. If you are transferring to a specific disk in the array then cache disk will not be involved. If you are transferring to a user share that hasn't been set to use cache then cache disk will not be involved. And the default setting for user shares is to not cache, so if you haven't changed that setting, the user share will not cache. Also, each user share has its own setting for this, so you would have to set it for each user share you want to use cache. There is also a setting in Global Share Settings to enable cache. If cache isn't enabled there then no user share will use cache.

Thanks Trurl, i did see that option but didn't realise it had to be enabled. 

 

Can that option be enabled while there are transfers in progress?

20 minutes ago, zver333 said:

Thanks Trurl, i did see that option but didn't realise it had to be enabled. 

 

Can that option be enabled while there are transfers in progress?

Yes.   The option applies to where new files will be placed - the ones already being transferred will continue unaffected.

Microservers come with write cache disable in the bios, change to enable.

Microservers come with write cache disable in the bios, change to enable.

Tell me more about this. I'm running 3 microservers and never heard this before. Will it make any great difference?

Sent from my LG-D855 using Tapatalk

28 minutes ago, superloopy1 said:

Will it make any great difference?

It will make for this:

17 hours ago, zver333 said:

Initial sync was between 32-38Mb/sec.

Sync should be 100MB/s+

From what I have read I believe it is recommended to have a UPS to gracefully shutdown/keep the array going.

 

If power goes out in the middle of an operation you can corrupt the data. In my current setup I think 50Mb/sec is maximum attainable for the system.

 

Enabling cache on SSD seems to be a good option for smaller transfers as it writes to fast SSD and later moves files to raid. Once cache is exhausted it slows down again.

 

I'm almost ready to add a second storage drive to the array, will be interesting to see what happens to speed.

7 minutes ago, zver333 said:

From what I have read I believe it is recommended to have a UPS to gracefully shutdown/keep the array going.

An UPS is definitely recommended, but power going out in the middle of a transfer will still corrupt data with write cache disable, though possibly less files affected, and most all other boards, including for example Supermicro server boards come with write cache enable.

Sync should be 100MB/s+

Thanks. I do have ups so i can safely(?) enable write cache if i read your replies correctly, yes.



Sent from my LG-D855 using Tapatalk

Correct

11 hours ago, johnnie.black said:

An UPS is definitely recommended, but power going out in the middle of a transfer will still corrupt data with write cache disable, though possibly less files affected, and most all other boards, including for example Supermicro server boards come with write cache enable.

 

And all newer file systems uses different solutions of doubly-writing or write and replace to make the file system able to recover back to a stable state where it's basically just the last write operations that will roll back in case of a power loss. So it's very uncommon to have to scan and repair any file system after a power loss with newer file systems. Some file systems will replay or rollback based on journals of ongoing write operations just before the power loss.

 

Some file systems like BTRFS will perform the write operations in a sandbox and at the last moment relink the internal structures to point to the new sandbox instead of the old data - so depending on when the power loss happened, the disk either had time to relink with the new sandbox data or stayed with the old data and have an unfinished sandbox that can be emptied and the space returned back as unused.

 

It's more important to consider if write cache should be on or off when considering removable media - USB-connected disks, thumb drives, memory cards. Especially since many of these media are normally used with stupid file systems that does not have any recovery functionality. FAT-16 and FAT-32 doesn't support journals or copy-on-write transactional updates.