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

[Thomas Haynes <[e-mail]>]

> On Jul 18, 2017, at 2:45 PM, Rick Macklem <[e-mail]> 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
>