On Fri, 2018-06-22 at 17:49 -0400, Chuck Lever wrote:
> Hi Bruce-
>
>
> > On Jun 22, 2018, at 1:54 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx>
> > wrote:
> >
> > On Thu, Jun 21, 2018 at 04:35:33PM +0000, Manjunath Patil wrote:
> > > Presently nfserr_jukebox is being returned by nfsd for
> > > create_session
> > > request if server is unable to allocate a session slot. This may
> > > be
> > > treated as NFS4ERR_DELAY by the clients and which may continue to
> > > re-try
> > > create_session in loop leading NFSv4.1+ mounts in hung state.
> > > nfsd
> > > should return nfserr_nospc in this case as per rfc5661(section-
> > > 18.36.4
> > > subpoint 4. Session creation).
> >
> > I don't think the spec actually gives us an error that we can use
> > to say
> > a CREATE_SESSION failed permanently for lack of resources.
>
> The current situation is that the server replies NFS4ERR_DELAY,
> and the client retries indefinitely. The goal is to let the
> client choose whether it wants to try the CREATE_SESSION again,
> try a different NFS version, or fail the mount request.
>
> Bill and I both looked at this section of RFC 5661. It seems to
> us that the use of NFS4ERR_NOSPC is appropriate and unambiguous
> in this situation, and it is an allowed status for the
> CREATE_SESSION operation. NFS4ERR_DELAY OTOH is not helpful.
There are a range of errors which we may need to handle by destroying
the session, and then creating a new one (mainly the ones where the
client and server slot handling get out of sync). That's why returning
NFS4ERR_NOSPC in response to CREATE_SESSION is unhelpful, and is why
the only sane response by the client will be to treat is as a temporary
error.
IOW: these patches will not be acceptable, even with a rewrite, as they
are based on a flawed assumption.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
