Have one 44GB ISO file sitting on my cache disk. Manually started the Mover script. Here's what the syslog says:

 

Dec 24 11:33:35 Tower logger: mover started
Dec 24 11:33:35 Tower logger: moving movies/
Dec 24 11:33:35 Tower logger: ./movies/temp/3D Blu-Rays/someMovie.iso
Dec 24 11:33:36 Tower logger: >f+++++++++ movies/temp/3D Blu-Rays/someMovie.iso
Dec 24 11:59:42 Tower shfs/user0: shfs_write: write: (28) No space left on device
Dec 24 11:59:42 Tower logger: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
Dec 24 11:59:42 Tower logger: rsync: write failed on "/mnt/user0/movies/temp/3D Blu-Rays/someMovie.iso": No space left on device (28)
Dec 24 11:59:42 Tower logger: rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7]
Dec 24 11:59:42 Tower logger: rsync: connection unexpectedly closed (28 bytes received so far) [sender]
Dec 24 11:59:42 Tower logger: rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]
Dec 24 11:59:42 Tower logger: mover finished

 

The "movies" share is configured as "Most-free" with Split-level 2 and "disk1" as excluded disks. The "included disks" edit field is empty.

 

My disk3 already has iso files in the "movies/temp/3D Blu-Rays" folder, so has disk7. disk3 has 43GB free space. disk7 has 1.1TB free. So why does the Mover pick disk3? Makes no sense to me at all. Seems to be a bug in the Mover disk selection.

 

Besides: It would be nice if the Mover could check whether a file can possibly fit on a chosen harddisk before it starts moving it. Otherwise a partial file will be created, which just messes up things.

Your split level setting is telling unraid to keep everything below temp on one disk. Thus it's trying to put all your 3d blu rays on one disc and failing when that disc runs out of space.

 

If you saved them to like /movies/3d blu-rays/

I think it will act how you expect.

Hmmmm... You're right, it's my fault...   

 

I'd still like the Mover to be clever enough to not even try copying a file if it won't fit, anyway.

From what I understand, linux does not know the size of a file being moved. To compensate this, the mover checks the hard drive for the min free space available setting for the mover. I think common practice is to set at 2x the largest file you would place on the server. I do agree since the file already exists on the cache why can it not use simple logic to compute available disk space compared to the file size trying to be moved.

Split level has precedence over allocation method.