[6.5.3] unRaid trying to move a file of 107GB from cache to a disk with 106GB free

You need to have the Minimum Free Space value for the share to be larger than the largest file you will be copying.    That stops a disk with less than that amount of free space from being selected as the target by mover.

10 minutes ago, itimpi said:

Minimum Free Space value for the share

 

I will try your suggestion. Thanks.

 

 

Edited June 29, 2018 by FlorinB

Did it, my biggest file is 200GB, however now the mover is not moving any kind of file from cache to the array as there is no disk into array with such amount of free space. 

I understand that for unRaid it is not possibile to know how big is a file when it is copied over network, however from cache to array it should be able to decide what to do with each file copied.

 

Unfortunately that is not how unRAID currently works.     If non of your disks have enough free space for the file then you have a problem as unRAID will never split a file across disks.

2 minutes ago, itimpi said:

If non of your disks have enough free space for the file then you have a problem as unRAID will never split a file across disks.

I am aware of this, but it is not my situation. There is enough free space (107GB) for the file on 2 disks (see the green highlights) from array, nevertheless Mover is trying to copy the file to a disk where it is not enough space.

But the minimum free space that you set was 200GB, and no disk has 200GB available on it.

What value do you have for Minimum Free Space?    It needs to be larger than the file you are trying to copy.  That is the only way you will get mover to select the correct disk.   The problem is that is not mover that selects the disk (and can thus take into account the file size) but the underlying unRAID disk handler.

45 minutes ago, itimpi said:

You need to have the Minimum Free Space value for the share to be larger than the largest file you will be copying.

The largest file that I will be copying is 200GB.

3 minutes ago, Squid said:

But the minimum free space that you set was 200GB, and no disk has 200GB available on it.

At this moment one of the large files is 107GB. I see no point to adjust the settings on Minimum Free Space for the share everytime I am copying a different file size. 

6 minutes ago, itimpi said:

What value do you have for Minimum Free Space?    It needs to be larger than the file you are trying to copy.

Right: 200GB > 107GB

6 minutes ago, itimpi said:

That is the only way you will get mover to select the correct disk.

Does the Minimum Free Space mean that I should have at least that amont of space free to move any file there? Because just this happened earlier.

6 minutes ago, itimpi said:

The problem is that is not mover that selects the disk (and can thus take into account the file size) but the underlying unRAID disk handler.

For this reason I have raised the bug report. renamed the topic from Mover... to unRaid...

Edited June 29, 2018 by FlorinB

It is not a bug in unRAID but the way it is designed to work.   The problem is that once the free space disk drops below the value then unRAID stops copying new files to the drive.    

 

i think you are probably going to have to manually copy these very large files directly to the target disk (which bypasses the Minimum Free Space setting) or you are going to have to add a lot more disk space.

41 minutes ago, itimpi said:

The problem is that once the free space disk drops below the value then unRAID stops copying new files to the drive.    

True and expected to behave like that. I am also aware that unRaid is not RAID, therefore I cannot copy a file bigger that the biggest disk from array (assuming that is empty)

41 minutes ago, itimpi said:

i think you are probably going to have to manually copy these very large files directly to the target disk

This is a no go as long as there is free space on more than one disk into array. I am expecting that unRaid is smart enough to know what to do with the available resources.

 

Quote

Allocation Method:  High Water

 

This setting determines how unRAID OS will choose which disk to use when creating a new file or directory:

High-water Choose the lowest numbered disk with free space still above the current high water mark. The high water mark is initialized with the size of the largest data disk divided by 2. If no disk has free space above the current high water mark, divide the high water mark by 2 and choose again.

Is it doing the red marked election one time or multiple times?

 

Edited June 29, 2018 by FlorinB

44 minutes ago, FlorinB said:

Is it doing the red marked election one time or multiple times?

 

As many times as necessary until a disk has more free space available than the highwater mark

13 minutes ago, Squid said:

As many times as necessary until a disk has more free space available than the highwater mark

Quote

High Water

The high water allocation method attempts to step fill each disk so at the end of each step there is an equal free space left on each disk. The idea is to progressively fill each disk but not constantly go back and forth between disks each time new data is written to the array. Most times, only a single disk will be needed when writing a series of files to the array so the array will only spin-up the needed disk. The high water level is initially set equal to one-half of the size of the largest disk. A new high water level is again set to one-half of the previous high level once all the disks have less free space than the current high water level.

Source: https://lime-technology.com/wiki/Un-Official_UnRAID_Manual#High_Water

For my unRaid:

Maximum disk size: 1TB

1st Pass: 500GB

2nd Pass:250GB

3rd Pass: 125GB

4th Pass: 62.5GB

On the green marked there is enough space, however it is under 3rd Pass

On the yellow marked there is not enough space, but is also under 3rd Pass

The red marked is belob 4th Pass.

 

Can be the water mark changed to 1/4 or other value instead of 1/2? this will probably help.

 

 

 

Use Most Free instead.

8 hours ago, Squid said:

Use Most Free instead.

Did it, but this is a just a workaround. Same like copying the file manually to a disk where there is enough space.