Cache drive (Appdata?) filling up

[lordmarqui]

I'm having issues with my cache drive (where my appdata share is mapped to) filling up when I download files via Sabnzbd. I've poured over all the posts and videos I can find, which has helped me narrow the issue down to what I think is a "leaky" or maybe an improperly mapped path inside of the docker instance itself...

 

That said, I new to this and only think that might be the issue and am here asking for some advice.

 

I'm attaching my logs for some guidance. 

 

I would appreciate any help the community could offer. Thanks in advance!

samson-diagnostics-20220105-2227.zip

[trurl]

None of your disks are full in those diagnostics, but appdata has some files on disk6, so perhaps it overflowed at some point (system share also has files on disk6). And of course nothing can move open files so you would have to disable Docker in Settings and run mover to get those moved.

 

Post docker run for sab.

 

[lordmarqui]

thanks for the reply...

 

so the initially i had a completely full cache drive to the tune of 500gb, where all 500gb were consumed by my docker image and appdata share... i deleted my docker image but the appdata folder was also incredibly large and i couldnt restart the docker service, so i changed the appdata share settings to No and invoked Mover to offload appdata. It appears it went to disk6. i then rebuilt docker and changed the share preference for appdata back to Prefer. Fast forward to now. I've rebuilt Docker and examined every path to ensure the mappings had the correct leading / when needed, etc... Testing out the downloads, which began this whole issue, I see that the problem persists...

 

I just stopped docker services and attempted to run Mover, but nothing happened. Meaning, the cache drive didn't decompress...

 

Sab's Docker Run is below:

 

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-sabnzbd' --net='proxynet' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '8181:8080/tcp' -p '8090:8090/tcp' -v '/mnt/user/downloads/':'/data':'rw,slave' -v '/mnt/user/appdata/binhex-sabnzbd':'/config':'rw' 'binhex/arch-sabnzbd'

f9eca668b41adf5f4cb6dfed537f9150c005bd080334e69df97c40680fb202b3

[trurl]

4 minutes ago, lordmarqui said:

changed the appdata share settings to No and invoked Mover to offload appdata.

mover ignores cache-no and cache-only shares, moves cache-yes shares from cache to array, and moves cache-prefer shares from array to cache. So setting it to no will not have gotten anything moved. Setting it to prefer will move to cache, except as noted

27 minutes ago, trurl said:

nothing can move open files so you would have to disable Docker in Settings and run mover to get those moved.

 

8 minutes ago, lordmarqui said:

I just stopped docker services and attempted to run Mover, but nothing happened. Meaning, the cache drive didn't decompress...

Not sure what you mean by "decompress". You can see how much of each drive is used by each user share by clicking Compute... for the share on the User Shares page, or using the Compute All button.

 

10 minutes ago, lordmarqui said:

Sab's Docker Run

container path /data, which is where you should have the application set to save downloads, is mapped to the downloads user share, which is cache-yes in those diagnostics, so those would go to cache and later be moved to the array according to the mover schedule, default is once per day in the middle of the night.

[lordmarqui]

I misspoke re the appdata share. It successfully moved to the array when I invoked mover prior to rebuilding everything. 
 

as far as now, can you clarify your advice?   That is correct that I have the downloads share pointed to a separate ssd cache pool just for downloads. The other cache pool is where the system- and appdata are pointed to. 
 

does that help?

[trurl]

8 minutes ago, lordmarqui said:

the downloads share pointed to a separate ssd cache pool just for downloads. The other cache pool is where the system- and appdata are pointed to. 

That makes sense and agrees with the settings you had in diagnostics, and seems like a good setup. Whether those shares still have files on the array, you can check yourself as mentioned

30 minutes ago, trurl said:

how much of each drive is used by each user share by clicking Compute... for the share on the User Shares page, or using the Compute All button.

or post new diagnostics.

 

Other than that, not sure what further advice you are looking for. Are you really downloading enough to fill that ssd in one day?

[lordmarqui]

Here are the Share utilizations per drive after clicking Compute:

• appdata 257GB total:
  • Cache: 236 GB
  • Disk 6: 14.0 GB
  • Disk 7: 2.96 GB

From my reading, appdata should at most be 10% of that. Any thoughts? I will post new log files below in case that's helpful.

samson-diagnostics-20220106-0029.zip

 

To reiterate, the downloads are going to a separate cache pool (called cache_ssd)...

 

My appdata and system shares go to another cache pool, which are the drives that are getting filled obnoxiously fast at the moment and that I'm seeking advice on how to correct.

Edited January 6, 2022 by lordmarqui
EXTRA INFO

[lordmarqui]

Woke up this morning and the cache pool is maxed to 511GB, where the Appdata share ballooned to fill it all...

 

Not sure where to go next... I'm sure there's an obvious issue that I'm missing but can't seem to pin it down.

 

Appreciate everyone's help ahead of time.

[itimpi]

You could look at the sub-folders within the appdata share to see which container the space is associated with.

[lordmarqui]

As an update it turns out that my Unifi Controller was using 1TB!!! Which makes sense that everytime Mover ran, it would take data off the array and move back to the cache pool because that's how I set it to run (Cache Priority without a min amount of memory free). Deleted, ran trim and the server now hums. Thanks everyone!