Issue with appdata share set to cache 'prefer'

[Chad Kunsman]

I have a 1TB platter cache drive which is also where my appdata share is set to as 'prefer', so that it will write to cache first, and write to array if cache fills up, but will bring it back to cache once the mover runs. 

 

I've found that running Docker containers will lock some of these files, and they will get stuck on an array drive unless the containers are stopped while the mover runs. 

 

Based on my workflow, I do anticipate hitting the min free-space on my cache from time to time, but I want to avoid having files get written to the array then have problems getting moved back due to locked files. 

 

My min-free space is set pretty high on cache (20gigs). What would happen if I switched my appdata share to only use cache rather than prefer? Does the 20 gig of min-free-space get respected even by a share set to cache only? In other words, would there still be a danger of me filling the drive and then I would end up getting disk full errors when docker tries to write?

 

Ideally, I'd like my appdata share to have a lot of buffer or flexibility to write what it needs to the cache drive, but other file copies would simply move to the array after the cache drive got too full.

 

Or is the only best answer to leave it at 'prefer' and just manually stop the docker containers and invoke the mover any time I happen to see appdata files get locked onto an array drive? 

 

Thank!

[tdallen]

Hi -

 

Is it necessary for you to move large volumes of data through appdata?  I'd suggest setting appdata to "only" and targeting the size of appdata to be *relatively* constant / consistent while moving large, transitory files through a different share if possible.

[Chad Kunsman]

I do not move large amounts of data through appdata share. In most use cases, I will be moving large amounts of data between the shares on the array, which are cache enabled, but not cache prefer. This means it's likely my cache will fill up until min-free space is reached, then the copy will switch directly to array. 

 

My appdata share is cache prefer, and it has files that are written regularly (due to Plex and assorted config/library updates), but doesn't grow in size very quickly. 

I anticipate filling up my cache drive occasionally with these large copy jobs, because cache drive is used for any array copies since my array shares are set to cache enabled.

 

If I do a large copy between my array shares, the cache could fill up, and then my appdata share can no longer write data to its share due to min-free space being reached, so it starts to write to the array. Then, when the mover runs later, it cannot move the files back to cache because the docker containers have locked them. I would have to stop docker containers and restart mover, then restart docker containers. 

 

 

[tdallen]

In that case I think I'd take the "standard" approach, which is to set appdata to cache "only" and reduce the min-free setting on appdata to slighly larger than the size of the largest file that might realistically be written to it.

 

It sounds like your combination of an active set of Dockers which are constantly creating files and periodic copy jobs which can fill up your cache drive are a bad combination.  If the settings changes above don't fix it, maybe time for a larger cache drive?  Or if it works for you, don't cache writes to the array.  I don't, I find normal write operations directly to the array to be quite reasonable, and I turn on Turbo Write (in my sig) when I need it to be really fast.  There's also a plugin that can turn on Turbo Write automatically.

[Chad Kunsman]

Thank you. I will check out turbo-write. I don't know much about it. 

[tdallen]

The disadvantage of Turbo Write is that it spins up all of your disks.  The advantage is a big boost in speed.  I get around 40-60 MB/s writing directly to the array without a cache drive or Turbo Write, but I get in excess of 70 MB/s writing directly to the array with Turbo Write.  Under ideal conditions I can get full line speed - 112 MB/s.  For example, this shows a large write.  At first it's fast, as the write is cached into RAM.  Then it slows down - standard array write speeds.  Then I turn on Turbo Write and you can see the speed max out a 1 Gbps Ethernet link.