Subject: FW: [nfsv4] Re: [pnfs] what error should be returned to animpatientclient?

From: "Iyer, Rahul" <[email-masked]>
Date: Wed, 11 Apr 2007 14:59:33 -0700

Forwarding to the list as my alias caused a bounce
Regards
Rahul

> -----Original Message-----
> From: Iyer, Rahul 
> Sent: Wednesday, April 11, 2007 2:54 PM
> To: [email-masked]'; [email-masked]
> Subject: RE: [nfsv4] Re: [pnfs] what error should be returned 
> to animpatientclient?
> 
>  
> 
> > -----Original Message-----
> > From: Mike Eisler [mailto:[email-masked]]
> > Sent: Wednesday, April 11, 2007 2:42 PM
> > To: [email-masked]
> > Subject: RE: [nfsv4] Re: [pnfs] what error should be returned to 
> > animpatientclient?
> > 
> > 
> > --- "Noveck, Dave" <[email-masked]> wrote:
> > 
> > > > - Return a new error, say: NFS4ERR_INPROGRESS. I don't 
> really like
> > > >   this because it is accomodating a broken client. 
> > > 
> > > The accommodation consists of giving him an error so he can
> > note that
> > > he has done something wrong and fix it.  I'm not against
> > that sort of
> > > accommodation.
> > 
> > How is the client going to fix it? Is there a new trend in 
> artificial 
> > intelligence that causes NFSv4 clients to fix themselves? 
> Can we get 
> > this AI agent on NFSv3 clients? :-)
> > 
> 
> How about the client tearing down the session, 
> re-establishing it and retrying the operation? 
> 
> > > 
> > > > - Return NFS4ERR_DELAY. I like this because it uses an existing
> > > >   error and so is not providing accomodation to brokeness.
> > > 
> > > So the broken client will not get fixed.  DELAY is a normal and 
> > > expected error which indicates the server is not ready to do 
> > > something, and that it isn't the client's fault.  So the
> > problem won't
> > > get fixed as easily.
> > > 
> > > Why is this better?
> > 
> > NFS4ERR_DELAY at least is an explicit indication that the 
> client needs 
> > to back off.
> > 
> > > 
> > > Would you still object if the error were NFS4ERR_BROKEN_CLIENT or 
> > > somethng else that made it absolutely clear the client is
> > not supposed
> > > to do this and we are only providing the error in the 
> interests of 
> > > getting the client fixed.
> > 
> > I'd like to avoid punishing customers for choosing bad clients.
> > I used to do that, and lost business. I fear that while 
> > NFS4ERR_INPROGRESS will just result in client implementors 
> exploiting 
> > it routinely, and possibly immediately re-sending, 
> > NFS4ERR_BROKEN_CLIENT is likely to be mapped to EIO and returned 
> > immediately to the app as a fatal error.
> 
> What if this were treated akin to a stale clientid error? In 
> which case it would mean tear down state, re-establish state 
> and retry the operation. It could also mean "mark this slot 
> useless, use other slots to clean up and re-establish state ASAP".
> 
> Regards
> Rahul
> 
> > 
> > If the consensus is to put either error into the spec, as 
> editor I'll 
> > do the job, under protest. But, no way will I ever write a 
> server that 
> > uses either error for this case.
> > > 
> > > -----Original Message-----
> > > From: Mike Eisler [mailto:[email-masked]]
> > > Sent: Wednesday, April 11, 2007 11:11 AM
> > > To: [email-masked]
> > > Subject: Re: [nfsv4] Re: [pnfs] what error should be 
> returned to an 
> > > impatientclient?
> > > 
> > > 
> > > 
> > > --- "Talpey, Thomas" <[email-masked]> wrote:
> > > 
> > > > Well, since the client violated the no-retransmit 
> principle, the 
> > > > server could simply close the connection. In fact on an RDMA 
> > > > transport, this may happen from the hardware itself. In
> > my opinion
> > > > this is what the server should do. But, if the server 
> is going to 
> > > > return an error, it should be NFS4ERR_SEQ_MISORDERED.
> > > 
> > > _MISORDERED is for when the client sends a sequenceid 
> that is less 
> > > than the sequencedid in the reply cache or greater (by two or
> > > more)
> > > than the sequenceid in reply cache.
> > > 
> > > I think there are four approaches:
> > > 
> > > - disconnect. One can look at my 2006 connectathon presentation as
> > >   to why that is a bad idea. Even though the spec allows it, don't
> > >   do it.
> > > 
> > > - The server just processes the request as if it it a new 
> one. This
> > >   is the Rick Macklem approach (see his presentation from 2006
> > >   connectathon). So there are two or more requests outstanding 
> > >   on the same slot, sequenceid pair. The first request
> > >   that completes on the server side gets to update the cache.
> > >   The client gets what it deserves. However I suspect this is
> > >   more complex logic for the v4.1 server than for the v4.0
> > >   server.
> > > 
> > > - Return a new error, say: NFS4ERR_INPROGRESS. I don't really like
> > >   this because it is accomodating a broken client. 
> > > 
> > > - Return NFS4ERR_DELAY. I like this because it uses an existing
> > >   error and so is not providing accomodation to brokeness.
> > > 
> > > > 
> > > > Remember, in this kind of situation, the slot and sequence are 
> > > > completely invalid, and the exchange is basically outside the 
> > > > session. There is no replay protection, and the client
> > will have to
> > > > use XID matching to detect the server's reply. Basically,
> > > 
> > > To make it clear to everyone, there is no slot table replay
> > protection
> > > because SEQUENCE is returning an error, versus a sequenceid and 
> > > slotid. Hence that is why the xid is needed.
> > > 
> > > > it's an invalid protocol request, almost as if the client
> > had sent
> > > > RPC garbage.
> > > > 
> > > > Tom.
> > > > 
> > > > At 10:19 AM 4/11/2007, Benny Halevy wrote:
> > > > >while reviewing the sessions text in draft-10 I realized
> > that it is
> > > > >not clear what error the server should return if the
> > client sent a
> > > > >new request on a slot that's still in use.
> > > > >
> > > > >In the currently linux implementation (in Andy's 
> latest patches)
> > > > >nfsd4_sequence() just allows that
> > > > >	status = nfs_ok;
> > > > >	if (nfs41_get_slot_state(slot) != NFS4_SLOT_AVAILABLE)
> > > > >		goto out;
> > > > >...
> > > > >out:
> > > > >	dprintk("%s returns %d\n", __FUNCTION__, status);
> > > > >	nfs4_unlock_state();
> > > > >	return status;
> > > > >
> > > > >I suggest returning NFS4ERR_BADSLOT or add a new error code
> > > > NFS4ERR_BUSYSLOT
> > > > >(other alternatives could be NFS4ERR_INVALID or
> > > > NFS4ERR_SEQ_MISORDERED).
> > > > >
> > > > >Benny
> > > > >_______________________________________________
> > > > >pNFS mailing list
> > > > >[email-masked]
> > > > >http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
> > > > 
> > > > 
> > > > _______________________________________________
> > > > nfsv4 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/nfsv4
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nfsv4
> > > 
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nfsv4
> > > 
> > 
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> > 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4