Yock

That can't be right, then there's something wrong some where. Using a default value of 1500 i saturate my 10Gpbs network.

Tried with the normal MTU value of 1500? Running with anything other than 1500 might/will cause a myriad of problems for home networks, using 9000 won't gain you any real speed in a 10Gpbs network anyway. Might fix the oscillating speed.

Maybe the CPU is stuck in low power state or something, a simple thing i would try is install the "tips and tweaks" plugin and put the CPU in performance mode to see if it makes any difference, at least then you will know if CPU is the problem, even if the transfers only go up by a few MB/s. While i hope it doesn't come to this, it's pretty simple to backup and restore docker containers with with the "Appdata Backup" plugin

Have you checked the CPU usage while transferring? Specifically single core and not just CPU %. Fuse + SMB uses a b*tt load of resources and as single threaded. Not saying this is the problem but might be a part of it.

Feels sketchy having to rely on a hard link move to having the file being added into the fuse layer which is why i keep asking. Anyway, many thanks again for the help, i will keep looking at this for a bit.

Just reread this and i want to be sure. The share i'm doing this on is part of the array, /mnt/user/media/ is on the array but also has a SSD cache. Download to /mnt/cache/media/download sonarr then moves to /mnt/user/media/tv/ and later mover moves to array. Sorry if i'm an idiot but want to be safe with my date.

Okay, so i guess i had misunderstood what disk share was, i thought the /mnt/cache would be a disk share basically. Guess i will be moving along with using /mnt/cache for download and have the arr's move it to /mnt/user with hard link after then, runs a lot faster. Many thanks for the help.

When searching google for stuff like this i keep finding warning about how it might end in missing files and such, those posts are rather old so wondering if that is still relevant or not.

Tried it, seems to work as i hoped it would, hardlinks work and mover moving them to array and everything. So i guess my question now is if there's a reason not to do it this way.

So i've been messing around a little with Sabnzbd to improve download and unpacking speed. Been thinking if it's possible to do a /mnt/cache/media/download and /mnt/cache/media/download/incomplete/ to bypass fuse and still have it all work together with the arr's. To clarify a little media is a cached array share so normally a fuse share (/mnt/user/media/), i want to use /mnt/cache/media/ to temporary bypass that while downloading and still be able to use hardlinks to speed things up as much as possible. Sorry if it's all badly explained, my english isn't really the best there is.

That's promising, shows it just my config that might have a small hiccup somewhere.

While not as extreme as SuberSeb's example i experienced a good drop in speed after having upgraded to the beta. Specially transfers over the fuse layer are effected. Used to be able to hit 700-800MB/s as well, now it barely goes past 600.

For Emby you need to add: NEOReadDebugKeys=1 OverrideGpuAddressSpace=48 In the docker container and everything works great inc. tone mapping. As with everything beta though, remember it's work in progress!

Okay. Looking at the picture you have set the arrs to bind to /mnt/user, this should be /mnt/user/Movies and Television.

I actually think i misunderstood what you wrote. You disabled cache for the shares but still want mover to move what the docker containers write?

You need to change the paths in the docker arrs containers. If you want a complete guide on how to set up arrs perfectly then there are the Thrash guides at: https://trash-guides.info/

Any possibility of making this available for Jellyfin and Emby users? Maybe a quick conversion to use their API?

Haha nearly killed my moms pets now when i yelled out in joy. It is working now! But if i have schedule on i can't manually move and vice versa, no biggie though. As a switch between turbo write on and off is really what i wanted anyways. I can't thank you enough for your help!

Copying some files to cache now to test, going to take a couple of minutes.

Just noticed on the picture my loggin is off.. Would probably help with that on... So... Jul 8 12:55:56 YockS kernel: mdcmd (46): set md_write_method 1 Jul 8 12:55:56 YockS kernel: Jul 8 12:55:56 YockS move: Usage: /usr/local/sbin/mover.old start [-e] <disk_name> Jul 8 12:55:56 YockS move: /usr/local/sbin/mover.old stop|status Jul 8 12:55:56 YockS move: <disk_name> must match pattern 'disk[0-9]*' Jul 8 12:55:56 YockS kernel: mdcmd (47): set md_write_method 0 Jul 8 12:55:56 YockS kernel:

Couldn't help my self so borrowed a secure computer and tested. Jul 8 12:27:49 YockS emhttpd: shcmd (87): /usr/local/sbin/mover start &> /dev/null & Jul 8 12:27:49 YockS kernel: mdcmd (36): set md_write_method 1 Jul 8 12:27:49 YockS kernel: Jul 8 12:27:49 YockS kernel: mdcmd (37): set md_write_method 0 Jul 8 12:27:49 YockS kernel: Is what i get.

The plugin was with default settings except for the force turbo writers. Sounds good that it works, i will look into it again when i get back to the server. Thanks for the help!

I don't think there is a workaround. It's sadly not possible for me right now to get near to anything administrative stuff on my server atm as i'm not home and don't want to use a computer/network not owned by me for that. But what i remember from logs is all it did was say something about starting the whole process, setting turbo writes on then next line was setting turbo writes off again and then nothing more. Test mode was disabled. Sorry i'm of practically no help but as said i'm not near the server atm.