Re: [nfsv4] I-D Action: draft-ietf-nfsv4-flex-files-10.txt

> The exception being NFS4ERR_DELAY - the client may want to retry the IO.

Another possible exception is the NFSv4.0 error NFS4ERR_LEASE_MOVED.

On Wed, Jul 19, 2017 at 2:50 AM, Thomas Haynes <loghyr@primarydata.com>
wrote:

>
> > On Jul 18, 2017, at 2:45 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> >
> > Thomas Haynes wrote:
> >>
> >>
> >> And as a client implementor, you are completely unaware of all of that.
> > I did a partial implementation of the client side last year and, at
> least for normal
> > operation, I think this statement is correct.
> >
> > One case where the client "might" need to know is when the server is
> doing
> > fencing.
> > - Unless I have misunderstood it, for the loosely coupled model, the
> client will
> >  see a NFS4ERR_ACCESS error when trying to do I/O on the storage server?
> > - But what error does the client see for the tightly coupled model?
>
>
> That would actually depend on how the fencing was done (it is totally up to
> the control protocol).
>
> The implementation might cause the storage device to return NFS4ERR_ACCESS
> or NFS4ERR_BAD_STATEID. The key point is that when the client gets an error
> from the storage device, it is responsible for returning the layout to the
> mds.
>
> The exception being NFS4ERR_DELAY - the client may want to retry the IO.
>
> >
> > Put another way, I think the client will need to be able to recognize
> the difference
> > between "fencing" and a typical NFS4ERR_ACCESS due to permissions on a
> tightly
> > coupled server.
>
> I don’t think so. Consider that the client already passed permission
> checking to
> get the file open and the layout. Now it could get the error either
> because it
> does not have write permission or the permissions on the file was closed.
>
> In any event, on any error, the client should return the layout (along
> with the error)
> to the MDS. It can then ask for the LAYOUT again. At which point the mds
> either
> assigns the new layout or does not provide a new layout (forcing IO to the
> mds)
> or it could return NFS4ERR_ACCESS if the permissions had changed.
>
>
> > (My partial implementation didn't include code to deal with mirrors or
> the case
> > where one mirror has failed or been fenced off, so I didn't deal with
> this case.)
> >
> > I'll dig into -11 later to-day.
> >
> > Thanks again, rick
> >
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>