I have a share named "media" which includes all array disks.

 

The "Split Level" is set to "Manual: do not automatically split directories"

 

For years, the mover would place new files from the cache into their corresponding directories without splitting. A few months back, it began splitting them - e.g. it creates /mnt/disk1/media/tv/[showname] on Disk 1 when /mnt/disk4/media/tv/[showname] already exists on Disk 4.

 

The "Minimum free space" setting for the share is 100G and /mnt/disk4 has 2884G free. (I see in the docs "In the event of there being conflicts between the Minimum free space, Split Level and the Allocation method settings in deciding which would be an appropriate drive to use, the Split level setting always wins," so that shouldn't matter anyway...)

 

/mnt/disk1 does have the most free space, so it seems like the Allocation Method might be superseding the Split level, contrary to that excerpt from the docs?

 

Any clues why Unraid might have begun splitting directories here?

 

I noticed the /usr/local/sbin/mover script has a debugging parameter it can pass to /usr/local/bin/move. "move --help" says I need to provide function names for that argument:

 

-d functions
  functions is a list of comma-separated function names to debug

 

What are the relevant values I can pass for "function names to debug"? I'd like to see as much output as possible about the mover's decisions to help understand its choices.

 

/boot/config/share.cfg:

Spoiler

# cat /boot/config/share.cfg
# Generated settings:
shareDisk="auto"
shareUser="e"
shareUserInclude=""
shareUserExclude=""
shareSMBEnabled="yes"
shareNFSEnabled="no"
shareNFSFsid="100"
shareInitialOwner="Administrator"
shareInitialGroup="Domain Users"
shareCacheEnabled="yes"
shareCacheFloor="2000000"
shareMoverSchedule="40 3 * * *"
shareMoverLogging="yes"
fuse_remember="330"
fuse_directio="auto"
fuse_useino="yes"
shareAvahiEnabled="yes"
shareAvahiSMBName="%h"
shareAvahiSMBModel="Xserve"
shfs_logging="1"

 

/boot/config/shares/media.cfg:

Spoiler

# cat /boot/config/shares/media.cfg
# Generated settings:
shareComment=""
shareInclude=""
shareExclude=""
shareUseCache="yes"
shareCachePool="cache"
shareCOW="auto"
shareAllocator="mostfree"
shareSplitLevel="0"
shareFloor="100000000"
shareExport="e"
shareFruit="no"
shareCaseSensitive="auto"
shareSecurity="public"
shareReadList=""
shareWriteList=""
shareVolsizelimit=""
shareExportNFS="-"
shareExportNFSFsid="0"
shareSecurityNFS="public"
shareHostListNFS=""

 

Edited April 25, 20242 yr by u.stu
Mention /mnt/disk1 has the most free space

Quick demonstration:
 

root@unraid:~# mkdir /mnt/disk4/media/foo/
root@unraid:~# echo foo > /mnt/disk4/media/foo/file1.txt
root@unraid:~# mkdir -p /mnt/cache/media/foo
root@unraid:~# echo bar > /mnt/cache/media/foo/file2.txt
root@unraid:~# find /mnt/disk?/media/foo /mnt/cache/media/foo
/mnt/disk4/media/foo
/mnt/disk4/media/foo/file1.txt
/mnt/cache/media/foo
/mnt/cache/media/foo/file2.txt
root@unraid:~# mover
mover: started
file: /mnt/cache/media/foo/file2.txt
mover: finished
root@unraid:~# find /mnt/disk?/media/foo /mnt/cache/media/foo
/mnt/disk1/media/foo
/mnt/disk1/media/foo/file2.txt
/mnt/disk4/media/foo
/mnt/disk4/media/foo/file1.txt
find: ‘/mnt/cache/media/foo’: No such file or directory
root@unraid:~#

 

Why would it create a new 'foo' directory on disk1 for file2.txt when there is already a 'foo' directory on disk4?

Apparently this is a confirmed bug, I didn't search back far enough in the forum before posting:

 

 

Just banging my head on the desk re this - my primary server is on 6.12.8, by backup unraid server is on 6.12.10 as of recently.

I like a nice tidy server - TV shows on two disks, Movies on a third, 4K and others on the next three disk - all was perfect on my live unraid server, and was perfect on my backup unraid server (that wakes up, gets an rsync, then shuts down) - and I just found a god awful mess of placement......

 

I would hope there was a 6.12.11 for this, and it is not shoved in with all the Unraid 7 stuff - as that is a major release and not something I want to take until it is well bedded in - many months I expect.

 

 

 

I'm getting fed up of the manual task to re-move stuff to where it should belong!!!!!!!   Grrrrrrrrr

This IS fixed in the 7.0.0 beta releases.

OK - sold me - I have added to task to my todo - to put the beta in to the backup server.  

I think I should move back to docker file rather than filesystem first however.  Seem to remember reading about an issue otherwise.

Not working for me in 7.0.1. Facing the same "bug" and noticed that this started today some while ago (without me noticing). Unfortunately still today despite 7.0.1.

 

In my case, this is not about "mover", but regular copy/transfer to the usershare with the *arrs.

 

Thoughts?

32 minutes ago, steve1977 said:

Facing the same "bug"

It won't be the same since that one is resolved, but it can be a new one, would need more details of what happened and the diagnostics.