i investigated quite a lot of time in finding out what the problem is
and i am trying to tell you what i found out:
I am using OpenBSD 3.5 as nfs-server and OS X latest version 10.3.4.
Havin this problems especially with the finder i started ktracing the finder and cp. What i basically found out that the big difference between the copy process with the finder and cp is that finder uses pread(0xd,0x18eec00,0x3000,0,0x36000)
and cp uses very traditional read(0x3,0x45b4,0x20000)
i really do not understand why they use pread since in my opinion read is the better approach since no explicit positioning inside the file is done.
but this did not satisfy my thirst of knowledge about this issue. So i also tried to find out how the buffer sizes are determined in both cases. cp seams to have a fixed buffersize, and finder somehow dynamically determines the buffersize (which is far to small).
But anyhow, i did not want to believe that this is the problem alone, since you told me that it works
so some further experiments.
i tried out with a linux box if it is a problem of the OpenBSD nfs-server, and the result was that the OpenBSD nfs-server performs perfectly (10MB/sec read and 10MB/sec write!!!)
so who is to blame?
then i of course also tried nfs from OS X to linux, and it worked better than to OpenBSD, even with the finder (5MB/sec read at least) ... but still there is something wrong i guess because i tried NFS from OpenBSD to Linux and it was 10MB/sec read and 10MB/sec write.
So there has to be something wrong with OS X.
But still i did not give up and tried to optimize the NFS parameters in my use case OSX to OpenBSD.
After trying out many combinations i came to a at least not too bad result
with cp 10MB/sec read , 5MB/sec write
with finder 4-5MB/sec read, 600KB/sec write
so maybe there are some things i can still try out like timeouts on the ip layer and things like that... and i guess i will try these things out
and finally here is how i mount now to get this result:
server:share /mnt nfs -U,w=8388608,-P,-r=8388608
very funny actual is this 8388608Bytes read and writesize because usually one uses exactly 8 KBytes and anything larger with UDP does not make sense. but somehow 8 KBytes works fine as long as u don`t use the Finder. the Finder needs this big value because then it uses a bigger blocksize for copy operations which improves speed a lot.
so i hope i could help now all people who do not have the problem *lol*
it seams that i am the only one
c.u.
m.