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

[Rick Macklem <[e-mail]>]

Thomas Haynes wrote:
[lots of stuff snipped for brevity]
> Taking both of these points into consideration, I’ve rewritten the section as:
>
> 2.1.  LAYOUTCOMMIT
>
>   The metadata server has the responsibility, upon receiving a
>   LAYOUTCOMMIT (see Section 18.42 of [RFC5661]), of ensuring that the
>   semantics of pNFS are respected (see Section 12.5.4 of [RFC5661]).
>   These do include a requirement that data written to data storage
>   device be stable before the occurance of the LAYOUTCOMMIT.
>
>   It is the responsibility of the client to make sure the data file is
>   stable before the metadata server begins to query the storage devices
>   about the changes to the file.  If any WRITE to a storage device did
>  not result with stable_how equal to FILE_SYNC, a LAYOUTCOMMIT to the
>   metadata server MUST be preceded by a COMMIT to the storage devices
>   written to.  Note that if the client has not done a COMMIT to the
>   storage device, then the LAYOUTCOMMIT might not be synchronized to
>   the last WRITE operation to the storage device.

Yes. This looks good to me. (except for the spelling of occurance;-)

> The concepts are presented to highlight the difficulties that a server developer will face.
Ok, I can buy into this. Maybe a sentence such as this near the beginning of the
document would clarify it for dumb-ass reader like me;-)

> I don’t think the client has to be aware of whether it is loosely or rightly coupled.
>
> Consider a NFSv3 storage device made by X. A MDS made by Y can use NFSv3 as
> the control protocol. It could CREATE to instantiate the data files, it could SETATTR
> the mode bits/uid/gid to fence, it can GETATTR to determine the change attribute,
> the mtime, etc.
>
> But if Y can recognize X and X provides some management APIs, then Y might be
> able to leverage those APIs as an additional control protocol.
>
> 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?

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.
(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