So I have a raid1 btrfs cache setup on 2 nvme drives, the only data I keep on these drives static are the system/appdata directories. I keep everything else in a monolithic "media" share that is cache->array.

Easy peasy.

During a large data download I managed to fill the cache faster than expected, my mover had not run yet (I dont use mover tuning) and it knocked my docker containers offline as expected in that scenario.

I kicked off the mover service and as it ran I was checking other things and noted that the balance task under the cache was saying it was "recommended". It showed it was scheduled to run 1st of the month so I ran it manually - "full re-balance." I don't know if this relates but I suspect so - thats why I mention it.

For some reason now my cache always shows 50% full. Running mover quickly (a few seconds) finishes without error. Utilization is 50% on cache. Looking on the pool (512GB cache) shows system/appdata taking 60GB and and "media" (the share that is cache->array) is 179GB.

Any ideas why the mover would ignore these files and not be moving them to the array? Would this relate to the balance task I manually ran?

I suspect I should rerun the balance but pick raid1 but figured I should get clarification before I got any deeper into this issue.
If I should manually move these files before performing this operation please let me know.

Enable mover logging, run the mover and post the diagnostics.

6 hours ago, Catch_22_ said:

During a large data download I managed to fill the cache faster than expected, my mover had not run yet (I dont use mover tuning) and it knocked my docker containers offline as expected in that scenario.

It would not have been a problem as long as you had set a Minimum Free Space value for the ‘cache’ pool to avoid it filling up too far. When the free space fell below this values new files would have started bypassing the ‘cache’ pool.

6 hours ago, Catch_22_ said:

Looking on the pool (512GB cache) shows system/appdata taking 60GB and and "media" (the share that is cache->array) is 179GB.

Any ideas why the mover would ignore these files and not be moving them to the array?

Probably because you have the settings for those shares to indicate they should only be on the ‘cache’ pool. That is the recommended settings for those shares for performance reasons. The diagnostics would allow us to confirm this.

As for minimum free space I thought I had that set but checking specifically, you are correct it is set to 0 so - yeah that for sure needs defined.

As for the cache to share moving, I do think that is correctly configured. I pulled dialogs with mover logging and I think I see the issue. It seems - somehow that a large set of the data on the cache that normally would be moved was duplicated somehow without being removed from the cache. Mover is balking that the files exist and when I check the paths per cache vs the array disk I do in fact see 2 sets of the same files.

I can only think this relates to a fail over event with the 2 drives or balance along with this event. One of the cache drives has a lot of "Write errors Read errors Flush errors Corruption errors" from that event when it went offline (rebooted and the device was up, passes SMART and has not made anymore errors since)

Thanks for pointing out the mover diag option! I couldn't find anything telling me "ouch!" - now I have that!

8 hours ago, JorgeB said:

Enable mover logging, run the mover and post the diagnostics.

ok, even after cleaning up the dups I still have something disconnected here.

I was going to move everything off cache and reformat it - stopped my dockers, I changed the shares over to array only and kicked off a move but none of my appdata/system is moving.

I know I can manually move things but I'm curious why its not functioning as expected. Log attached.

f4-424-diagnostics-20260605-1056.zip

1 hour ago, Catch_22_ said:

appdata/system

Both are set to array only, so the mover won't touch them. Also, note that you need to disable the Docker and VM services first.

2 minutes ago, JorgeB said:

Both are set to array only, so the mover won't touch them. Also, note that you need to disable the Docker and VM services first.

Both Docker and VM are off. VM has always been off and Docker is stopped for this troubleshooting.

RE: the Array only comment - Perhaps I'm not understanding something - setting the array only on shares where data is on the cache - shouldn't mover re-home these to the array?

33 minutes ago, Catch_22_ said:

setting the array only on shares where data is on the cache - shouldn't mover re-home these to the array?

No mover only operates on shares where both primary and secondary storage options are set.

(my shares)

None of these shares will move except the 3rd one from the top, you can see it's "Cache -> Array" and mover will only work on that specific one

Edited June 5Jun 5 by MowMdown

Thank you for confirming!

There is actually a benefit to mover only operating on shares that are assigned both storages.

I do something weird where I have certain data to only be read from on my array BUT, I also have the same share exist on a pool where other data can be read/wrote too without ever moving anywhere.

I do this because the "archival" data wont fit on my pool and I dont want a lot of small things move to the array but I want to be able to read from ALL the data across the entire system through a single entry point.

Edited June 5Jun 5 by MowMdown