Hi,

I have installed 7.1.4 and have a 500 GB cache, of which 372 GB is in use. There are many hard drives in the array with only 1.1 GB free, no hard drive has more than 16 GB free - so I am using almost all of the available storage.

I have a share with the following settings:

Minimum free space: 16GB

Primary storage: Cache

Secondary storage: Array

Allocation method: High-water

Split level: Automatically split any directory as required

When the mover now starts, it tries to move all data from the cache to the full hard disks. Of course it doesn't work to move 372 GB to a hard drive that only has 1.1 GB free - in the log afterwards I can see how it tried for an hour to move every single file. Some smaller files worked and in the end I had a hard drive with only 2.58 MB free.

At first I thought it was due to the Mover Tuning plugin, but even after uninstalling it, it still doesn't work.

Is this behaviour a bug in the system or is it by design? I have often read here in the forum that ‘Minimum free space’ does not do what the normal user expects.

Edited June 29, 20251 yr by Flyk3

Please post the diagnostics and the share name.

Unfortunately, this is not possible. I started loading the diagnostics almost 8 hours ago and it is still busy. Every few minutes a new line appears with the following values:

sed -i 's/\/mnt\/cache\/Media\/Folder\/File.jpg \/mnt\/disk13\/Media\/Folder\/File.jpg.partial (28) No space left on device/\/\/..e\/.../g' '/fserver-diagnostics-20250629-0923/logs/syslog-previous.txt'

Reboot and post new diags.

9 hours ago, JorgeB said:

Reboot and post new diags.

Ok, here it is.

Edited July 1, 20251 yr by Flyk3

The array disks are all 100% full, Media share floor is set to 32GB, and not disk has more than that available, so the mover cannot move anything from that share.

Yes, but why does the mover try it anyway? Actually, it should see that everything is full and do nothing. Instead, it wants to move everything to some disc.

44 minutes ago, Flyk3 said:

Yes, but why does the mover try it anyway?

Only when trying does it check if there's space or not.

I still don't understand it. When I start the mover now, it sees that all drives are full, sees that my shares have at least 16 GB minimum free space set and then tries to move all files to a full drive.

My question is, why does it do that? Why does it ignore minimum free space? Why does it try to move a 5 GB file to a drive that only has 1 GB free?

1 hour ago, JorgeB said:

Only when trying does it check if there's space or not.

2 hours ago, JorgeB said:

  3 hours ago, JorgeB said:

Only when trying does it check if there's space or not.

Are you saying that I should deactivate the mover?

If you don't intend to get more space on the array, you might as well disable it for that share, or you can just disable mover logging so that it doesn't spam the log, and if in the future there's space, it will move the data.

2 hours ago, JorgeB said:

If you don't intend to get more space on the array, you might as well disable it for that share, or you can just disable mover logging so that it doesn't spam the log, and if in the future there's space, it will move the data.

That still doesn't explain why the mover starts without first checking whether there is enough space.

Here is the explanation text for ‘Minimum free space’ in the share settings: ‘The minimum free space available to allow writing to any disc belonging to the share.’

That is a clear explanation! First check if there is enough free space, then allow writing.

It all worked in unRaid version 6.x.

1 hour ago, Flyk3 said:

It all worked in unRaid version 6.x.

It was always like that, it never checked before trying to move the files.

That setting DOES work in normal operation. However you also need to read the part of the documentation that mentions the setting is ignored if it is being over-ridden by Split Level.

You also need to realise that the part of the system that selects a drive for a new file has no idea how large a file is involved (at that point it has a logical size of 0) which is why it mentions that the setting should be larger than the biggest file you intend to write to avoid a subsequent ‘out-of-space’ error.

Thank you, that's finally a normal answer.

But I have selected ‘Automatically split any directory as required’. Why should this option overwrite the ‘Minimum free space’? That is already the most flexible setting.

Let's assume I have a folder in the share. ‘Automatically split any directory as required’ is selected. All my hard drives are enabled for the share. At some point, the folder was moved from the mover to disk1. In the meantime, disc1 is full. I am now copying more files into this folder. These end up in the cache. Now you say that ‘Automatically split any directory as required’ overwrites the ‘Minimum free space’ and the mover will try to move the new files to Disk1 even though it is full?

I have read that the setting should be larger than the largest file I intend to write.

Assuming my cache is 2TB and empty. There is only one hard drive on my array and that has 1TB free. I have set “Minimum free space” to 20 GB and am now copying 180 files of 10 GB each to the cache. This means a total of 1.8 TB. According to your explanations, the mover will now try to write these 1.8 TB to the disc that only has 1 TB free. This would mean that you must always have as much free space on your array as the size of the cache.

If the mover does not know how much memory is free on the discs, I understand the behavior. But for me as a human being it makes no sense that you can set ‘Minimum free space’ and the system ignores it. In which scenario does that make sense?

In Unbalance you can also set the minimum free space and it works. Unbalance is a free plugin. Why can't Lime Technology also develop such a free space check?

14 minutes ago, Flyk3 said:

Now you say that ‘Automatically split any directory as required’ overwrites the ‘Minimum free space’ and the mover will try to move the new files to Disk1 even though it is full?

No - it is Split Level that takes precedence. I got your situation mixed up with somebody else’s

The decision as to which drive to use is made at the individual file - and is not based on the total size. If no drive has the required amount of free space then you will get an ‘out-of-space error. The relevant sub-system is not clever enough to remember ghis do it can move onto the next file and get the same error again.

It would be nice if there was some way of doing this more tidily but I think it would be none-trivial to implement and is only an issue if your disks are overfilled - most people then simply get another dtive or replace an existing one with a larger one.

I am not a professional programmer, but it took me less than 10 minutes to write the following script. Thanks to AI. It checks the size of the original folder in the cache and it checks the free space on each disc. You can specify how much space must be on the disc AFTER the folder is moved to the drive. If no disc has enough free space, the move process will not start. It has passed the first tests, but still needs more work.

But I just wanted to show that it is not impossible to code something like this. I really wish that Lime Technology would integrate a proper free space check into the mover.

#!/bin/bash

SOURCE="/mnt/cache/Media/"

MIN_FREE_GB=10

# Loop through each disk in the array

for disk in /mnt/disk*; do

# Check free space (in GB)

free_gb=$(df -BG "$disk" | awk 'NR==2 {print $4}' | tr -d 'G')

# Get the size of the SOURCE folder (in GB)

size_gb=$(du -sb "$SOURCE" | awk '{printf "%d", $1/1024/1024/1024}')

if (( free_gb - size_gb >= MIN_FREE_GB )); then

echo "Moving $SOURCE to $disk ..."

rsync -avh --remove-source-files "$SOURCE" "$disk/Media/"

else

echo "Not enough space on $disk (required: $size_gb GB, available: $free_gb GB)"

fi

done

Edited July 1, 20251 yr by Flyk3