[CentOS] NFS help

Wed Oct 26 13:35:33 UTC 2016
Matt Garman <matthew.garman at gmail.com>

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!