Arnold,
Just out of curiosity, have you tried a different transfer method like rsync to see what the results are? Do you have any dead symbolic links in the directory? We used to run into issues with cp because it tried to resolve the link even though it wasn't going to copy it.
Jeff
On Thu, Oct 17, 2013 at 4:37 PM, Arnold de Leon a-toasters@deleons.comwrote:
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.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters