I am sorry, I am stepping into the conversation late and may not fully understand all aspects of the situation but I wonder if it may make sense to set up a server process on the NFS server machine that simply listens for incoming requests to perform a file copy and then does so as requested - only locally. If files in question are large - which I suspect they may be, given the timeouts becoming an issue - that may resolve the issue and help speed things up at the same time. Cheers, Boris. On Wed, Oct 26, 2016 at 9:35 AM, Matt Garman <matthew.garman at gmail.com> wrote: > On Tue, Oct 25, 2016 at 7:22 PM, Larry Martell <larry.martell at gmail.com> > wrote: > > Again, no machine on the internal network that my 2 CentOS hosts are > > on are connected to the internet. I have no way to download anything., > > There is an onerous and protracted process to get files into the > > internal network and I will see if I can get netperf in. > > Right, but do you have physical access to those machines? Do you have > physical access to the machine which on which you use PuTTY to connect > to those machines? If yes to either question, then you can use > another system (that does have Internet access) to download the files > you want, put them on a USB drive (or burn to a CD, etc), and bring > the USB/CD to the C6/C7/PuTTY machines. > > There's almost always a technical way to get files on to (or out of) a > system. :) Now, your company might have *policies* that forbid > skirting around the technical measures that are in place. > > Here's another way you might be able to test network connectivity > between C6 and C7 without installing new tools: see if both machines > have "nc" (netcat) installed. I've seen this tool referred to as "the > swiss army knife of network testing tools", and that is indeed an apt > description. So if you have that installed, you can hit up the web > for various examples of its use. It's designed to be easily scripted, > so you can write your own tests, and in theory implement something > similar to netperf. > > OK, I just thought of another "poor man's" way to at least do some > sanity testing between C6 and C7: scp. First generate a huge file. > General rule of thumb is at least 2x the amount of RAM in the C7 host. > You could create a tarball of /usr, for example (e.g. "tar czvf > /tmp/bigfile.tar.gz /usr" assuming your /tmp partition is big enough > to hold this). Then, first do this: "time scp /tmp/bigfile.tar.gz > localhost:/tmp/bigfile_copy.tar.gz". This will literally make a copy > of that big file, but will route through most of of the network stack. > Make a note of how long it took. And also be sure your /tmp partition > is big enough for two copies of that big file. > > Now, repeat that, but instead of copying to localhost, copy to the C6 > box. Something like: "time scp /tmp/bigfile.tar.gz <IP address of C6 > host>:/tmp/". Does the time reported differ greatly from when you > copied to localhost? I would expect them to be reasonably close. > (And this is another reason why you want a fairly large file, so the > transfer time is dominated by actual file transfer, rather than the > overhead.) > > Lastly, do the reverse test: log in to the C6 box, and copy the file > back to C7, e.g. "time scp /tmp/bigfile.tar.gz <IP of C7 > host>:/tmp/bigfile_copy2.tar.gz". Again, the time should be > approximately the same for all three transfers. If either or both of > the latter two copies take dramatically longer than the first, then > there's a good chance something is askew with the network config > between C6 and C7. > > Oh... all this time I've been jumping to fancy tests. Have you tried > the simplest form of testing, that is, doing by hand what your scripts > do automatically? In other words, simply try copying files between C6 > and C7 using the existing NFS config? Can you manually trigger the > errors/timeouts you initially posted? Is it when copying lots of > small files? Or when you copy a single huge file? Any kind of file > copying "profile" you can determine that consistently triggers the > error? That could be another clue. > > Good luck! > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >