Mover Fills Up, causing copy to fail

[jeffreywhunter]

Latest version of unRaid.  I'm copying a LOT of files via SMB (windows 10 to unRaid share) which works great.  I have 500gb Cache drive, but the drive is filling up and then windows copy hangs.  I thought that once the cache disk fills up, that it would skip cache and write directly (but slower) to the physical drive.  Am I misinformed?  Is there a setting somewhere I've missed?  Mover is set to execute every 3 hours.

 

Here's the share settings

Share name: Acronis
Comments: Acronis Backups
Use cache pool (for new files/directories):Yes
Select cache pool:Cache
Enable Copy-on-write:Auto
Allocation method: High-water
Minimum free space: 0KB
Split level:Automatically split any directory as required
Included disk(s):All
Excluded disk(s):None

 

Thanks in advance!

[alturismo]

50 minutes ago, jeffreywhunter said:

Is there a setting somewhere I've missed?

 

read about "min free space" to get the expected behaviour, i also wonder why you have to set it but read up into it

 

as note, when you fill up the array (like new setup etc or just mass moving new files) rather use /mnt/user0/... which is the share but array disks ONLY without using the cache, like this you spare the extra disk usage by moving from cache to array which is wanted anyway in this scenario.

 

sample with a share called "Media" with "cache: yes"

 

/mnt/user/Media/ <- will copy to cache first and move when mover is triggered

/mnt/user0/Media <- will copy directly to the array drives instead without using the cache

 

here you see the difference, i have a 2 tb cache nvme

 

[jeffreywhunter]

8 minutes ago, alturismo said:

 

read about "min free space" to get the expected behaviour, i also wonder why you have to set it but read up into it

 

as note, when you fill up the array (like new setup etc or just mass moving new files) rather use /mnt/user0/... which is the share but array disks ONLY without using the cache, like this you spare the extra disk usage by moving from cache to array which is wanted anyway in this scenario.

 

sample with a share called "Media" with "cache: yes"

 

/mnt/user/Media/ <- will copy to cache first and move when mover is triggered

/mnt/user0/Media <- will copy directly to the array drives instead without using the cache

 

here you see the difference, i have a 2 tb cache nvme

 

Thanks!  I was aware of User0, however, I thought that resulted in slower performance copying the files?  Probably not a big deal.  I get 113MB/s with the cache.  Also, how would I setup the User0 disk for an SMB share from Windows 10?  I don't see that option in the included disks.

[alturismo]

 

19 minutes ago, jeffreywhunter said:

how would I setup the User0 disk for an SMB share from Windows 10?

 

 

something like this

 

 

will result in

 

 

you can do this in real time (without stopping the array) by editing this file on your flash drive, BUT ON YOUR OWN RISK  thats what i just did  to show 

 

this is not recommended, rather stop the array and use the SMB extra part in settings

 

 

[trurl]

Not sure how this got sidetracked into thinking about user0. It can be dangerous to have different views to the same files, since you might try a move or copy where the source and destination are the same, which would result in data loss.

 

12 hours ago, jeffreywhunter said:

I thought that once the cache disk fills up, that it would skip cache and write directly (but slower) to the physical drive.  Am I misinformed?  Is there a setting somewhere I've missed?  Mover is set to execute every 3 hours.

For a cache-prefer or cache-yes user share to overflow to the array, Unraid must decide cache doesn't have enough space.

 

Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has more than Minimum Free, the disk can be chosen and if the file won't fit the write will fail. If a disk has less than Minimum, Unraid will choose a different disk.

 

You must set Minimum Free for the share to larger than the largest file you expect to write to the share. And you must set Minimum Free for cache to larger than the largest file you expect to write to cache.

 

Also, running mover more often won't help anything. Mover is intended for idle time. It is impossible to move from cache to slower array as fast as you can write to cache. If you intend to write more than cache can hold at one time, set the user share to cache-no.

[jeffreywhunter]

So it seems then, that for shares used for moving large files (aka device backups), it makes sense to have those shares be cache-no.  Otherwise, you'd have to set the minimum free to be very large.

 

Thanks!

Edited December 10, 2021 by jeffreywhunter

[jeffreywhunter]

5 hours ago, trurl said:

Also, running mover more often won't help anything. Mover is intended for idle time. It is impossible to move from cache to slower array as fast as you can write to cache. If you intend to write more than cache can hold at one time, set the user share to cache-no.

 

My cache appears to be 'stuck' for some reason.  Even when I run mover, nothing happens.  How can this be?

 

 

[trurl]

9 minutes ago, jeffreywhunter said:

when I run mover, nothing happens

Probably there is nothing to move because your user shares are set so that all files are already where they should be.

 

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.

 

Attach diagnostics to your NEXT post in this thread.

[jeffreywhunter]

On 12/10/2021 at 4:52 PM, trurl said:

Probably there is nothing to move because your user shares are set so that all files are already where they should be.

 

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.

 

Attach diagnostics to your NEXT post in this thread.

Diagnostics attached.  I think I didn't fully understand some of the settings.  Specifically Cache-prefer - didn't realize that would prefer to leave the files on the cache, I thought it meant use the cache unless full...  I physically moved the files myself using MC, so good for now.  I've looked at all the shares, they are either Cache-yes (for shares that don't have huge files - documents, music, movies, etc) and Cache-no for very large files (like PC backups) which now go directly to share.  I'm having a problem where the server runs for a few days then locks up.  I suspect it an unrelated logging issue but I'm not sure.  I see a lot of these in the log...

 

Dec 24 10:00:30 HunterNAS kernel: netlink: 4 bytes leftover after parsing attributes in process `gs-server'.
 

The GS-Server works flawlessly and there's no issues with it running - other than the log messages, I've not had much luck figuring this out.  But that's a topic for a different thread!   

 

hunternas-diagnostics-20211224-1016.zip