I've been using network storage forever (RAID hardware, software, and dedicated NAS devices.) I understand the concepts. SO I figured unRaid looked compelling and I had some extra hardware to try. But the more I use unRaid 7 the more I have questions about proper configuration. 

 

I have two 4TB data drives with a 6TB parity in the array (just to start.l) I also have a 256GB SSD in the pool, named cache. All the docs talk about using the cache to buffer writes to speed up ingest of data while a backend process will write that data to the parity protected array. Sounds Good.

 

The first transfer test didn't show any activity in the Pool SSD (I thought it was a default process). I dug into the docs and found references to a "Use Cache" setting in share settings. In 7.0.0 there is no option for this in the WebGUI? It finally dawned on me that there were likely setting files on the USB drive and sure enough I found the share settings file with shareUseCache="no". I changed it to yes and tried transferring files again. Still no activity on the pool cache drive.  Restarted the system. Still nothing.

 

I dug back into the Manual and found something about Primary / Secondary storage. So I reconfigured the share for the pool cache SSD as the primary and the array as the secondary. Now I was getting traffic pool cache SSD but nothing on the Array.  That is until transfered data exceeded the size of the SSD and the transfer ended with an error. That's not expected. 

 

What am I missing here?     

1 hour ago, streamdynamics said:

What am I missing here?   

Minimum Free settings for cache and for each user share. And probably mover schedule.

 

Unraid decides where to put a file before it begins writing it.

 

For pools, if Primary pool (cache in your case) has less than Minimum Free for the pool, it will go to Secondary instead. This is known as overflow.

 

For user shares, if a disk has less than Minimum Free for the share, another disk will be chosen.

 

For example, Minimum is set to 20G, pool has 25G free. Since this is more than Minimum, the pool can be chosen. If you write a 15G file, after writing the pool will have 10G free, which is less than Minimum, so further writes will overflow.

 

Another example, Minimum is 20G, pool has 25G free. Since this is more than Minimum, the pool can be chosen. If you write a 30G file, it will fail when it runs out-of-space.

 

Default mover schedule is once-per-day in the middle of the night.

 

If you need to write more at one time than cache can hold, don't cache.

 

For initial data load, unassign parity, set shares to Primary:array, then build parity after initial load is complete.

Thank you that makes more sense now. I was thinking there was more fuzzy logic used in backend file management.

 

I also was thinking that there might be more than one drive write/activity at a time (sudo strip)... writing of multiple files to the array at a time. Meaning File1 to drive A and File2 to drive B... With only me using it for the initial data load (repository of large system image files) I'm only seeing one file write to one drive at a time.  So, the main benefit of the array is not throughput performance but allowing multiple different sized drives to be used with the parity protection as backup for all of them.  

 

This makes me think in terms of using the Array for near storage and an SSD raid (ZFS?) in the pool for faster performing storage and virtualization (future). 

 

I think I'm getting it!

 

Cheers,

Thank you again.