Try NFSv4. Compound ops will help with high latency links.

Sent on my bb
 
From: Arnold de Leon [mailto:a-toasters@deleons.com]
Sent: Thursday, October 17, 2013 11:37 PM
To: toasters <toasters@teaparty.net>
Subject: Re: Slow copy of a directory full of files via an NFS client across a WAN
 
I just tried NFSv2, similar results.  Same deadly embrace of request/reply which is death with a link with latency.

For this current test case this took over 5 minutes to copy 11MB of data in 600 files.

For reference

NFS (WAN 20ms) to NFS (WAN 20ms): 5 minutes
NFS (WAN 20 ms) to local disk:  50 seconds
Local disk to NFS (WAN 20ms ): 3 minutes 50 seconds
Local disk to local disk: 0.285 seconds
NFS (LAN 1ms) to NFS (LAN 1ms):  5 seconds

[I see that Peter also added data.  This is a bit of throwback for me, I've been around long enough to deal with the fun Usenet spool directories and joys of lots of small files]

The irony here is all I want is to make a copy of a directory which would be a trivial operation on the filer itself, I just need another reference to the directory.  The filer can make the copy when data is modified.  I'm wondering if I can do this with the OnTap API (I don't know about the APIs yet).  The other possible work around is using a host that is on the same LAN as the filer to do the copies.  I just can't believe that there isn't a simple solution to this.

Thanks everyone for the ideas and information.

 arnold





On Thu, Oct 17, 2013 at 2:28 PM, Mike Horwath <drechsau@gmail.com> wrote:
Do you require NFSv3?

Why not try NFSv2 - that will bypass the multitude of *ATTR calls going on a bit and may be better.

Only testing will tell, of course.