[CentOS] Fail Transfer of Large Files

[Jay Leafey]

Les Mikesell wrote:
> On 11/19/10 3:16 PM, Michael D. Berger wrote:
>> On my intranet, I sometimes transfer large files, about 4G,
>> to an CentOS old box that I use for a web server.  I transfer
>> with ftp or sftp.  Usually, before the file is complete, the
>> transfer "stalls".  At that point, ping from the destination box
>> to the router fails.  I then deactivate the net interface on the
>> destination box and then activate it.  Ping is then successful,
>> and the transfer is completed.  The transferred file is correct,
>> as verified with sha1sum.
>>
>> All connections are via cat6 wire.
>>
>> So what do you think?  Should I try changing the net card?
>> Any tests to run? Any other suggestions?
> 
> I haven't seen anything like that, at least in many years so it probably is 
> hardware related - but make sure your software is up to date.  As a workaround, 
> you might try using rsync with the --bwlimit option to limit the speed of the 
> transfer - and the -P option so you can restart a failed transfer from the point 
> it stalled on the last attempt.
> 

This does ring a bell, but the circumstances were a bit different.  In 
our case we were transferring large files between "home" and a remote 
site.  SFTP/SCP transfers were stalling part-way through in an 
unpredictable manner.  It turned out to be a bug in the selective 
acknowledgment functionality in the TCP stack.   Short story, adding the 
following line to /etc/sysctl.conf fixed the issue:

> net.ipv4.tcp_sack = 0

Of course, you can set it on-the-fly using the sysctl command:

> sysctl -w net.ipv4.tcp_sack=0

It helped in our case, no way of telling if it will help you.  As usual, 
your mileage may vary.
-- 
Jay Leafey - jay.leafey at mindless.com
Memphis, TN
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5529 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20101120/f79a32db/attachment.bin>