sea -
All of the files are in the 1 to 4 gb range. Most of them are right at 4gb. When tailing the log file, the ones that complete do so in a couple of minutes at most. I can't wait 'forever' but when the next one goes two hours without any progress, I'd call that a 'hang'. If it were the underlying FS, it should have presented problems prior to the DC move, and the scp copy should have the same issue. No, the only variable here is the network connection, and perhaps ftp's reaction to it. Given the apparent reduction in bandwidth, I'd expect it to be slower, but I wouldn't expect ftp to grind to a complete halt, while scp is able to do the same work.
---------- Post updated at 02:12 PM ---------- Previous update was at 02:06 PM ----------
Robin -
1 - no pipes, just plain files.
2 - no errors returned ... it just grinds to a halt. Before it does so, I tail -f the file and watch things go by. I can also see the time stamp on the file (ls -l) progressing every couple of minutes as it completes another file and writes the info about it. Then everything just stops moving.
3 - No network errors that I know how to log (I'm DBA, not Net Admin) but I'm willing to take a look if someone can tell me where.
3a - most of the files are at 4gb. Several of them move just fine, so it can't be file size alone, though I could see that being a 'necessary but not sufficient' component of the problem. I don't know about the possibility of the network speed and duplex switch, but I'll take that up with the Net Admin. Thanks for the idea.
---------- Post updated at 02:14 PM ---------- Previous update was at 02:12 PM ----------
Quote:
Originally Posted by
hicksd8
Since the problem occurred after relocation I'd be inclined to suspect the network. I'd write a script to ping the target, say, every 10 seconds (to avoid too much artificial network traffic) and leave it running in front of me. When the ftp 'hangs' is the ping still fast????
Good idea. I'll try to set up a test.