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

[Thomas Haynes <[e-mail]>]

> On Jul 18, 2017, at 1:15 AM, Rick Macklem <[e-mail]> wrote:
> 
> Here's one more:
> Last para of 2.3.1
>   As the client never receives a stateid generated by a storage device,
>   there is no client lease on the storage device and no prospect of
>   lease expiration, even when access is via NFSv4 protocols.  Clients
>   will have leases on the metadata server.  In dealing with lease
>   expiration, the metadata server may need to use fencing to prevent
>   revoked stateids from being relied upon by a client unaware of the
>   fact that they have been revoked.
> 
> What about a loosely coupled NFSv4.1 storage server?
> If won't have any stateids, but it will have a clientid and session.
> I doubt that the server wants to hold onto the clientid forever?
> - I'd suggest that this case might require a simple recovery of
>  ExchangeID, CreateSession when the client receives a
>  NFS4ERR_BAD_SESSION error from the storage server.
> 

While true, I’m not sure it needs to be called out.


> I don't know if you call this "lease expiration", but I would have thought
> of it that way, rick
> 
> ________________________________________
> From: nfsv4 <[e-mail]> on behalf of Rick Macklem <[e-mail]>
> Sent: Monday, July 17, 2017 6:39:41 PM
> To: Thomas Haynes; [e-mail]
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-flex-files-10.txt
> 
> First off. I'd like to thank both Thomas and David for their work on this. I am happy to see
> active work on it.
> 
> 1 - I think I mentioned this, but I no longer care about the stuff I posted last year.
>      (Basically the case where a server might only require one mirror to be written and
>       how quickly changes to a mirror were to be propagated. Others may still feel that
>       this is useful, but it no longer matters to me;-)
> 
> I am thinking of posting one issue at a time, since they probably require discussion.
> (If you'd prefer one post with everything in it, just let me know and I'll hold off on
> further individual posts and make one "collective" post.)
> Having said the above, here's the first one:
> 
>> 2.1.  LAYOUTCOMMIT
>> 
>>  When tightly coupled storage devices are used, 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 not
>>  include a requirement that data written to data storage device be
>>  stable upon completion of the LAYOUTCOMMIT.
> 
> - The above sentence seems to imply that the client is responsible to do COMMITs
>   and seems to contradict the following para., which suggests that the COMMITs
>   are required for "loose coupling" only.
> 
>> In the case of loosely coupled storage devices, 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.
> - I think it would be simpler for a client implementor (like me;-) to just apply
>  this para. to both loose and tight coupling (ie. just drop the part of the first
>  sentence up to the "," and say "It is the responsibility of the client.."
> OR
> - Make it conditional on a flag returned by the MDS.
> 
> In general, most of the "tight" vs "loose" coupling seems to be confusing to me.
> I can see that there may be the two cases w.r.t. security:
> 1 - Use the synthetic uid/gid and AUTH_SYS only.
> OR
> 2 - Use the same model as the MDS (same uid/gid/authenticator) and let the
>     MDS<->DS figure out how to implement it.
> Again, I think a flag returned by the MDS to indicate which security model is being
> used would be simpler than the "tight" vs "loose" concept. (The document can mention
> that some control protocol may be needed for the server implementation, but the
> client only cares what it needs to do and not how the server chooses to implement it.)
> 
> I just find the "loose" vs "tight" coupling a somewhat confusing "catch all" and I think
> a few flags returned by the MDS to the client will clarify what the client needs to do,
> but this is just a suggestion and I'm happy with anything that works. (I think this also
> applies to Data Server vs Storage Server. To be honest, I'd just get rid of all mention
> of these and just call them all data servers?)
> 
> Again, thanks for working on this, rick
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>