Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jan 2012 15:28:07 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        svn-src-head@FreeBSD.org, Rick Macklem <rmacklem@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: svn commit: r230516 - in head/sys: fs/nfsclient nfsclient
Message-ID:  <20120125152150.M1522@besplex.bde.org>
In-Reply-To: <2145461054.81036.1327460551572.JavaMail.root@erie.cs.uoguelph.ca>
References:  <2145461054.81036.1327460551572.JavaMail.root@erie.cs.uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Jan 2012, Rick Macklem wrote:

> Bruce Evans wrote:
>> On Wed, 25 Jan 2012, Rick Macklem wrote:
>>
>>> Log:
>>>  If a mount -u is done to either NFS client that switches it
>>>  from TCP to UDP and the rsize/wsize/readdirsize is greater
>>>  than NFS_MAXDGRAMDATA, it is possible for a thread doing an
>>>  I/O RPC to get stuck repeatedly doing retries. This happens
>>>  ...

>> Could it wait for the old i/o to complete (and not start any new
>> i/o?). This is little different from having to wait when changing
>> from rw to ro. The latter is not easy, and at least the old nfs
>> client seems to not even dream of it. ffs has always called a
>> ...

> As you said above "not easy ... uses complicated suspension of i/o".
> I have not tried to code this, but I think it would be non-trivial.
> The code would need to block new I/O before RPCs are issued and wait
> for all in-progress I/Os to complete. At this time, the kernel RPC
> handles the in-progress RPCs and NFS doesn't "know" what is
> outstanding. Of course, code could be added to keep track of in-progress
> I/O RPCs, but that would have to be written, as well.

Hmm, this means that even when the i/o sizes are small, the mode switch
from tcp to udp may be unsafe since there may still be i/o's with higher
sizes outstanding.  So to switch from tcp to udp, the user should first
reduce the sizes, when wait a while before switching to udp.  And what
happens with retries after changing sizes up or down?  Does it retry
with the old sizes?

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120125152150.M1522>