Good day, i am facing a problem related to SMB transfer failing consistently

 

1: When i transfer files via local network

2: When i transfer file wian Wireguard VPN

 

The problem is allways the same, a good transfer rate for 4-5 min, than drop to minimum / zero.

Demonstration video

 

 

Attaching here diagnostics file just after the transfer test.

 

I have tried a network disk attached or directly to share, it's the same.

Also i have tried to transfer to Cache or Array directly, no difference.

Tried multiple PC's, / different users / shares same result.

During transfer network ping to unraid server remains stable and i dont have any network loss

Any ideas what should i do ?

 

 

 

tower-diagnostics-20240416-1708.zip

Edited April 16, 20242 yr by oldguy

That suggests the devices are not keeping up with the transfer, your disks are SMR and the cache SSDs a white brand, do you have a non SMR disk you could test with?

I have 4 x TB SSD (pretty empty) (tested in raidz before), and 4 6TB HDD 2 parity 2 data.

I dont really understand your information, i am the only user of unraid, and loading a test file of 41 GB, the speed rate over vpn is 40mb/s at start.

When i transfer a file to cache / or to HDD's, you say they are not able to handle that transfer speed load so they drop speed and cut the transfer ?

Why the system do not decrease the transfer speed ?

58 minutes ago, oldguy said:

Why the system do not decrease the transfer speed ?

Because if the server is flushing the data slower it can cause temporary halts, could also be a network issue, assuming gigabit, transfer should start at 100MB/s while being cache to RAM, then slowdown to keep up with device speed, according to your video it's starting already at 50MB/s, suggesting the network has bandwidth issues, run iperf.

18 hours ago, JorgeB said:

Because if the server is flushing the data slower it can cause temporary halts, could also be a network issue, assuming gigabit, transfer should start at 100MB/s while being cache to RAM, then slowdown to keep up with device speed, according to your video it's starting already at 50MB/s, suggesting the network has bandwidth issues, run iperf.

 

Good day.

To verify all your information i did a test yesterday, but before that we can discard all the network issues, i have no network packet drops, the link is stable.

 

First test

Local network transferring 41 GB file full throttle 110 Mb/sec, the transfer dies in 1-2 minutes.

 

Second test

Winscp transfer over the local network directly to drive without rate limiting 80Mb/sec dies same 1-2 min

 

Third test

Winscp with rate limit to 20Mb/sec transfer never dies and finished.

 

With this information which confirms your say about cache, however instead of slowing down, it just hangs.

As i have tested the transfer via SCP and SMB with the comparable results i suppose we can assume the issue is not in underlyeing protocol but something deeper and related to software.

Lets say i take one HDD out, and put it directly into USB enclosure, i think that i will able to transfer files to that Hard Drive without any issue, and it will perform based on it's specification. In this case why i am not able to transfer files via SMB/SCP to a share at maximum speed possible, and need to rate limit my transfer ?

Thank you

 

 

 

Edited April 17, 20242 yr by oldguy

27 minutes ago, oldguy said:

With this information which confirms your say about cache, however instead of slowing down, it just hangs.

Still looks like a device problem to me.

 

28 minutes ago, oldguy said:

Lets say i take one HDD out, and put it directly into USB enclosure, i think that i will able to transfer files to that Hard Drive without any issue, and it will perform based on it's specification.

But that won't have parity slowing down the writes, so it's not an equal comparison, you can also temporarily disable parity (unassign it) and re-test, but test with more than one disk, in case there an issue with one of them, and ideally you would test with a non SMR disk, since write performance in those is usually inconsistent and can vary.