[nfsv4] [nfsv4] NFSv4 performance issues on a lagged network

[Bryce Harrington]

On Tue, Aug 29, 2006 at 07:19:25PM -0400, Talpey, Thomas wrote:
> Soft mounts... why? Might want to add "intr" so they're killable btw.

We had experienced some problems early on where the systems would get
blocked trying to unmount during reboot, so found soft mounting a bit
less troublesome.  However, it didn't eliminate the issue, and we ended
up adding a watchdog and power reset that solves all such issues, so
there really isn't any good reason why we're using soft instead of hard
mounts.  If they could be affecting the results, then we should switch
to hard mounts as you (and Chuck) recommend.

We're running one test using hard mounts now, and will see what affect
that has.
 
> I'm a little surprised the network stack is emitting ENETUNREACH here.
> But if those occur and the mount is soft, it would account for a lot.
> Personally I'd try to fix all three - use hard mounts fo testing, fix
> the RPC socket error handling, and figure out why the error comes
> up from the stack.
> 
> Back to my original motivation for the suggestion, one thing to play
> with is the effect of changing the rpc slot table size. If the network
> is flaky, but not fatally so, one result is that the rpc roundtrip time
> increases by unpredictable amounts. This in turn means that the
> client will run out of work to give the server (the default per-mount
> slot table is 16 requests). Increasing the slot table may help.

Okay, thanks, we'll try that!
 
> Have you used Chuck's whizzo NFS python statistics gathering
> script after these runs (before unmounting)? One really useful
> thing they produce is operation latencies, and rpc backlog. They'd
> be very interesting in this context. To me anyway. :-)
> 	<http://oss.oracle.com/~cel/linux-2.6/2.6.17/iostat-ms>

Ah, thanks, no I didn't know about these.  I'll give them a shot.

> Good stuff, btw. May take a little while to digest.

Cool, thanks for the feedback!

Bryce