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@xxxxxxxxx>
wrote:
> On Tue, Oct 25, 2016 at 7:22 PM, Larry Martell <larry.martell@xxxxxxxxx>
> 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@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
