4 minutes ago, Masterwishx said:

For users that have seen issues, please check new version that will be available tomorrow I hope.

Also, I want to thank @chodeus the developer of the amazing plugin: Folder View 3, which was kindly and has spent a lot of time improving this plugin in recent days, so everything should work better than before... :)

Anyone having issues with the next release please post your debug zip! It has been improved a lot to try make it easier to diagnose the fault and where improvements need to be made in the plugin. It is really hard to diagnose most things without it!

Next release is busy with stability and reliability improvements, skip lists and ignored folder fixes, moving threshold accuracy improvements, with some config warnings and road blocks to stop people putting in conflicting settings, improved per share settings and also improvements to the debug zip!

I take the blame if anything is more broken but testing on ZFS cache + XFS array it has been working well! Just a little more testing to go.

On 9/2/2026 at 9:57 AM, srpage said:

OK. I've discovered the issue. I am cross seeding torrent files that are hard linked. They are being double, triple counted in the calculations.
Any suggestions on how to fix?

All working again with the new pluggin.
Thanks guys.

I have a question about how the Freeing Threshold is intended to work, particularly with very large files. Before calling this a bug or edge case, I want to make sure I am not misunderstanding the setting or overlooking another option.

My primary pool is a roughly 7.25 TiB ZFS NVMe pool, with secondary storage on a ZFS HDD pool. The share is set Primary → Secondary, and Mover Tuning was configured with:

Moving Threshold: 65%
Freeing Threshold: 5%

I interpreted the 5% setting to mean that once Mover is triggered, it should continue selecting whole files until primary-pool usage gets approximately to 5%, possibly crossing somewhat below 5% when the final file is very large.

In a recent run, the primary pool started at about 85% used / 6.2 TiB. Mover Tuning selected approximately 4.7 TiB and successfully moved it, but finished with about 1.5 TiB / 20% still on the primary pool.

The unusual part of my workload is that many files are very large compressed backup containers, commonly 1–2 TB each. In this run, one file of 1,576,499,677,252 bytes was explicitly marked “keep on primary.”

Looking at the Mover Tuning action data and age_mover, I think I understand why. Immediately before considering that file, projected remaining usage was about 1.581 TB. Moving the file would have left only about 4.55 GB, which is below the approximately 391.7 GB represented by the 5% threshold.

The decision code appears to require projected remaining usage to remain at or above the threshold:

remaining_bytes_used[$1] >= $6

Therefore the entire large file is kept, leaving roughly 1.5 TB on the primary pool instead of allowing usage to cross below the 5% threshold.

I reproduced/confirmed the same comparison in both Mover Tuning 2026.08.29 and 2026.09.07.

Am I interpreting the Freeing Threshold incorrectly, or is there another setting intended to handle this? If not, could this be a large-file edge case where the whole-file decision causes Mover to stop substantially above the requested freeing threshold?

I have the Mover action list, debug log, exact calculations, and the relevant source-code section available if they would help.

Thanks for taking a look.

1 hour ago, LBro said:

I have a question about how the Freeing Threshold is intended to work, particularly with very large files. Before calling this a bug or edge case, I want to make sure I am not misunderstanding the setting or overlooking another option.

My primary pool is a roughly 7.25 TiB ZFS NVMe pool, with secondary storage on a ZFS HDD pool. The share is set Primary → Secondary, and Mover Tuning was configured with:

Moving Threshold: 65%
Freeing Threshold: 5%

I interpreted the 5% setting to mean that once Mover is triggered, it should continue selecting whole files until primary-pool usage gets approximately to 5%, possibly crossing somewhat below 5% when the final file is very large.

In a recent run, the primary pool started at about 85% used / 6.2 TiB. Mover Tuning selected approximately 4.7 TiB and successfully moved it, but finished with about 1.5 TiB / 20% still on the primary pool.

The unusual part of my workload is that many files are very large compressed backup containers, commonly 1–2 TB each. In this run, one file of 1,576,499,677,252 bytes was explicitly marked “keep on primary.”

Looking at the Mover Tuning action data and age_mover, I think I understand why. Immediately before considering that file, projected remaining usage was about 1.581 TB. Moving the file would have left only about 4.55 GB, which is below the approximately 391.7 GB represented by the 5% threshold.

The decision code appears to require projected remaining usage to remain at or above the threshold:

remaining_bytes_used[$1] >= $6

Therefore the entire large file is kept, leaving roughly 1.5 TB on the primary pool instead of allowing usage to cross below the 5% threshold.

I reproduced/confirmed the same comparison in both Mover Tuning 2026.08.29 and 2026.09.07.

Am I interpreting the Freeing Threshold incorrectly, or is there another setting intended to handle this? If not, could this be a large-file edge case where the whole-file decision causes Mover to stop substantially above the requested freeing threshold?

I have the Mover action list, debug log, exact calculations, and the relevant source-code section available if they would help.

Thanks for taking a look.

You're right with the freeing threshold and it was a bug in 2026.08.29. The threshold was tested against usage after the candidate file, and a kept file's size stayed in the running total, so everything after your 1.5 TB file was measured against a projected 4.55 GB and kept too. That's the 20% stop.

Fixed in 2026.09.07. With your reproduction/comparison is that the comparison you quoted is identical in both versions, what changed is the line above it, remaining_bytes_used[$1] = pool_bytes_used[$1] + net_delta[$1], which is now the usage before the file (your 1.581 TB) rather than after it (4.55 GB). So on 09.07 that file should move.

Either way, one 1–2 TB file is ~20% of your pool, so at 5% the mover will now essentially empty it. A minimum age or the skip list is a better lever if you want to keep the pool populated.

If you think the behaviour you're seeing is incorrect I'm happy to look at your debug zip and see if I missed anything!

Mover Tuning with Very Large Backup Files — NAS24 Test Results

What the graph shows

This Grafana graph was developed as both a testing and ongoing monitoring tool for NAS24. In one view it captures essentially the entire backup-transfer cycle: incoming network traffic, writes into the NVMe Supercache, growth of allocated Supercache space, the end of the FastCopy transfer, and the subsequent Mover drain from Supercache into the HDD Tank.

The left scale is throughput in MiB/s. The right scales show NVMe temperature and Supercache allocation.

Graph legend:

Red — Supercache Aggregate: Aggregate writes into the NVMe Supercache
Blue — Tank Aggregate: Aggregate writes to the five-HDD ZFS Tank
Light green — Supercache Read Aggregate: Data being read from Supercache during Mover
Orange — NAS24 NIC RX Aggregate: Total incoming network traffic to NAS24
White/Cyan/Purple/Green — NVMe temperatures: Temperatures of the four Supercache NVMes
Tan — Supercache Allocated TiB: Amount of the NVMe pool occupied over time

During the first portion of the graph, FastCopy is sending the backup to NAS24 while Supercache allocation rises almost linearly. At approximately 17:25 the incoming transfer ends. Supercache writes and network RX collapse, and the second phase becomes visible: Supercache is read while Tank is written as Mover drains the landing pool.

By the end of the graph, the transferred backup has been moved to Tank and Supercache has been completely drained and is ready for the next large backup.

Why this test is unusual

NAS24 uses a roughly 7.8 TB NVMe Supercache in front of a five-drive ZFS HDD Tank. The system was built this way because backup sessions can be many terabytes and the network can deliver data considerably faster than the HDD pool can comfortably absorb directly.

The workload is also atypical. Much of the data consists of very large AOMEI backup-container files, with individual files commonly hundreds of GB and sometimes approximately 1–2 TB. That makes Mover's individual file decisions unusually visible.

For this test the backup share used:

• Primary storage: Supercache

• Secondary storage: Tank

• Mover direction: Supercache → Tank

• Mover Tuning start threshold: 65%

• Freeing threshold: 5%

• Age filtering: Off

The objective is to let Supercache absorb a large high-speed backup and then automatically reclaim that NVMe capacity afterward for the next backup.

The problem found during testing

Initial testing was performed with Mover Tuning 2026.08.29. Results were disappointing: despite a 5% freeing threshold, Mover could stop with approximately 20% / 1.5 TB still occupying Supercache.

The Mover Tuning developer investigated the results and confirmed a bug in the freeing-threshold calculation. With our exceptionally large files, the problem was particularly visible. One file involved in the investigation was approximately 1.576 TB by itself.

The developer corrected the problem in Mover Tuning 2026.09.07 and explained precisely why the earlier behavior occurred.

Final test with the corrected version

The final FastCopy workload was:

• 7,752,616 MiB transferred

• Approximately 7.39 TiB / 8.13 TB decimal

• 28 files

• 2:56:42 elapsed

• 766.7 MB/s FastCopy average

• Verify disabled

• Sustained network throughput exceeded 1,000 MiB/s for extended periods during the Supercache-filling stage, with NAS24's Grafana NIC RX trace commonly running roughly 1,050–1,250 MiB/s

The FastCopy figure is the end-to-end average for the complete copy job, while Grafana shows NAS24's instantaneous aggregate network receive rate, so the two figures measure different things.

Supercache filled to approximately 6 TiB during the transfer. After FastCopy finished, Mover continued transferring the data to Tank.

Most importantly, it did not stop at the approximately 20% utilization point seen with the earlier plugin version.

Supercache ultimately drained completely.

Why a 5% threshold can result in an empty pool

With files this large, a 5% freeing threshold should not be interpreted as Mover stopping at precisely 5%.

Mover works with complete files. On a ~7.8 TB pool, moving another 1–2 TB file can take utilization from substantially above the threshold directly to essentially zero.

For this particular backup workload, that is exactly what I want: maximum available Supercache capacity for the next multi-terabyte backup.

For users who want particular files retained on the primary pool, minimum-age or skip-list controls may be more appropriate than relying solely on a low freeing threshold.

Conclusion

With Mover Tuning 2026.09.07, NAS24 is now doing what this architecture was intended to do:

High-speed network backup → fast NVMe landing pool → automatic post-transfer drain to ZFS HDD storage → empty Supercache ready for the next backup.

The timing of this testing was fortunate. Only a couple of days earlier, the same configuration produced disappointing results because of the freeing-threshold bug. The developer responded quickly to the reported behavior, identified the cause, corrected it, and explained the change.

Many thanks to the Mover Tuning developer for the exceptionally quick investigation and fix.

Testing, analysis and documentation assisted by my tireless AI lab partner.

LBro

Glad the fix works for you! Thankyou for the report.

In the new version will be added support for Translation, thanks to @chodeus

So added Russian, German and French language.

Users with native German or French can update/fix it in github.

Any other language also can be added by users on github to plugin.

I have some requests:

1. Is it possible to add mover status somewhere in the UI for mover progress?

2. What should I query in a script to see if a move operation is running? Check if age_mover is running or something else?

3. Can you add an option to prioritize large files for move?

For 1

When checking/rebuilding parity, for example, Dashboard and Main show a quick overview of % complete, speed, and a rough ETA. The parity % completion is also exposed in the bottom left of the UI as well (where it normally says "Array started"). Basically, there are multiple places to see not only parity check is running, but also progress and status (running, paused, etc.).

I'd love to have mover activity similarly exposed in the UI. Ideally, UI elements would be identical to parity, but these are the specific attributes I would like exposed somewhere:

• % complete/file move progress

• mover speed

• ETA

• Maybe a flag/warning if things are moving unusually slow

I understand that with the mixture of HDD/SDD storage, that information would be inherently inaccurate. However, I'm not looking for accuracy; simply exposing the real-time rsync statistics would be helpful.

For 2

I have a script that pauses heavy IO processes when parity is running that I'd like to expand to the mover process. What should I query for the mover plugin? Is looking for the age_mover process sufficient, or should I run something else?

For 3

This is purely preference, and I don't have a strong need for it other than clearing data from unRAID cache quickly when mover is triggered.

I would like an option for mover to sort based on file size and start with the largest files first. This is to clear space quickly and delay the slowdown of thousands/tens-of-thousands of disparate small files that occur randomly throughout the discovery process.

Move files based on minimum size option is almost there. However, it ignores all the small files I would still want moved eventually. Instead, I propose a mover option to prioritize based on file size. My vision is to add two config options:

• "Prioritize file size" toggle:

  • When false (default): the following is hidden and set to auto/existing file mover behavior

  • When true: unhides/makes the following selectable:

• "Sort preference" drop-down:

  • auto, or none? (default): existing mover behavior

  • largest to smallest

  • smallest to largest

Edited September 20Sep 20 by NichollsGlen

Hi,

1. Yes, it can be done, although it isn't built into Mover Tuning and the setup is fairly involved. I use Grafana for the graphs, fed by InfluxDB and Telegraf on Unraid. That lets me graph cache/pool activity and network throughput while Mover is running and retain the history afterward. There is an Unraid-specific Telegraf/Grafana video guide here that covers the basic monitoring stack. I then added custom metrics/panels for the mover/cache information I wanted.

   These might help:

   

   Grafana Labs

   

   Unraid System Dashboard V2 | Grafana Labs

   2. & 3. - Not sure, possibly the Developer could help?

Take care,

LBro