Menu
According to the needs of the experiment, I set the MTU to 8000. After doing this, when I use scp to copy large files, it stalled with 0.00%. I tried scp -l or scp -C and turning tcp_sack on/off, but it still didn't work. And I can't change the MTU size for experiment result comparison. Is there any other way to help?
750
The reason for scp to stall, is because scp greedily grabs as much bandwith of the network as possible when it transfers files, any delay caused by the network switch of the firewall can easily make the TCP connection stalled.
Yes, if both ends support sftp - after scp remoteuser@remotehost:/absolute/filename . fails you can resume by doing sftp remoteuser@remotehost and then reget /absolute/filename to resume the download.
Short description. The maximum size for SCPs policy documents is 5,120 bytes.
Copying files and directories with SCP or Rsync Secure Copy (SCP) uses SSH to copy only the files or directories that you select. On first use, Rsync copies all files and directories and then it copies only the files and directories that you have changed. It does not copy all the files and directories again.
An attempt at a comprehensive solution, as there could be several problems and limitations depending on your situation.
My preferred option: using rsync doesn't give this problem and is a bit more versatile in my opinion, e.g. it keeps track of which files are already there, so if the connection ever does break it can pick up from where it left off - try the --partial flag too - among other things.
Instead of
scp local/path/some_file [email protected]:"/some/path/" you can just do
rsync -avz --progress local/path/some_file [email protected]:"/some/path/" I've tested this on several occasions when scp would give me the same problem it gave you - and now I just use rsync by default.
Not a solution for OP as the MTU is fixed in this situation (and probably not the issue here), but if the culprit is a slow/unreliable connection between the two drives, setting a speed limit reduces the delays which make the TCP connection stall - at the expense of a slower transfer of course. This is because scp grabs all the bandwidth it can get unless you specify the maximum data rate in kilobits, like so:
scp -l 8192 local/path/some_file [email protected]:"/some/path/" This doesn't always work though.
scp's -C option can speed up the transfer, reducing the probability that the transfer stalls.
As mentioned by the OP, and here.
sudo sysctl -w net.ipv4.tcp_sack=0 (or similar)
Again an MTU fix, not necessarily of the transfer specifically though:
ifconfig eth0 mtu 1492 or on newer (Linux) systems:
ip link set dev eth0 mtu 1492 If all else fails, this lists another handful of potential solutions not included here.
The more exotic hpn bug may be at fault too.
73
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
