On 30/01/18 21:31, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 07:03:17PM +0000, Terry Barnaby wrote:
It looks like each RPC call takes about 0.5ms. Why do there need to be some
many RPC calls for this ? The OPEN call could set the attribs, no need for
the later GETATTR or SETATTR calls.
The first SETATTR (which sets ctime and mtime to server's time) seems
unnecessary, maybe there's a client bug.
The second looks like tar's fault, strace shows it doing a utimensat()
on each file. I don't know why or if that's optional.
Even the CLOSE could be integrated with the WRITE and taking this
further OPEN could do OPEN, SETATTR, and some WRITE all in one.
We'd probably need some new protocol to make it safe to return from the
open systemcall before we've gotten the OPEN reply from the server.
Write delegations might save us from having to wait for the other
operations.
Taking a look at my own setup, I see the same calls taking about 1ms.
The drives can't do that, so I've got a problem somewhere too....
--b.
Also, on the 0.5ms. Is this effectively the 1ms system tick ie. the NFS
processing is not processing based on the packet events (not
pre-emptive) but on the next system tick ?
An ICMP ping is about 0.13ms (to and fro) between these systems.
Although 0.5ms is relatively fast, I wouldn't have thought it should
have to take 0.5ms for a minimal RPC even over TCPIP.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
