I am using Unraid 6.11.2. I am transferring files from my MacBook on Ventura, but have also tried in a Win11 VM on my Mac.

 

When I copy a Season to my Plex Share there is unexpected behavior. Let's say each episode is 100MB. When copying the Season folder I will get the expected transfer speed up until 100MB has been copied. The transfer then pauses, 0bps for 3-8 seconds, before continuing again only to pause again after the next 100MB has been transferred. I can copy files successfully but this adds quite a bit of time when copying many files.

 

I have tried turning cache off and on, reconstruct write on and off, ethernet over wireless, copying vs moving, and MacOS and Windows. I even created two dummy files with mkfile 2G testfile1.txt and mkfile 2G testfile2.txt, where it's the same story. Copies the first 2GB just fine and then pauses before copying the second. Then after all files are copied it sits for about 5 seconds and the completes.

I have also tried copying to a different share and got the same results. Granted these shares are setup basically the same and use the same cache pool.

 

Granted I don't really know how to begin troubleshooting this nor do I fully understand SMB. But I did observe that during the copy both the servers CPU usage and Memory usage were nothing out of the ordinary.

Edited November 6, 20223 yr by Kameechewa

This behaviour is often seen when you have a lot of free memory and set the values "vm_dirty_ratio" and "vm_dirty_background_ratio" to very unsane values.

What happens is that incoming data is first packed into RAM until the configured value is reached. Then Linux fires up the disks and (slowly) writes out the data freeing up the ram cache. In the mean time incoming data is still appended to RAM until the 2nd value is reached.

Now Transfer is halted. Disks are still written and it needs quite a time until enough RAM is freed up again to accept more incoming data.

This is an up-down process you can easily watch with the details window of window's file copy.

At the end of the file, wether there is free ram or not, SMB has to wait for a successful write to disk until the last package is acknowledged.

This is supposely the ugly delay that you are noticing.

 

What helps in this situation?

Install a fast cache drive (SSD even better NVMe SSD) and set the shares to "yes" mode!

The writes will go to the fast SSD/NVMe instead of the slow Hardisk directly. They are 3 to 20 times faster, so the end delay is either very short or even not existent anymore.

 

Thank you for your reply. Unfortunately I have no idea what these vm_dirty values that you speak of are. I have never heard of them and therefore have likely not modified them.

 

I do have a cache pool made of two 240GB SSDs, WDBAGU2400ANC-WRBB, and most shares are set to use it. The writes are indeed happening on this pool when copying data. I can't honestly say when I first noticed this issue, maybe when going from 6.10 to 6.11? I hadn't done any large transfers for a while before this so I'm not sure.

If you have installed Tips and Tweaks (Community Applications) there you can change the values for vm.dirty_background_ratio and vm.dirty_ratio.
After changing the values to 1 (1% of total RAM, in my case 64GB) the pause after each file reduced from 5-10 sec to less than 1 sec on a HDD.

ooh, I notice that my longish answer from last night never made it to this forum (lost ???)

Anyway I also recommended "Tipps & Tweaks" to set those values to a very low number (start writing earlier, dont wait for a big pile that blocks at the end).
I also said I would disable one of those Cache SSDs, to see if getting rid of the double writing speeds up things too. (If yes, you still can decide afterwards if you prefer it safe but slow or fast an a bit risky).