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

[Rick Macklem <[e-mail]>]

Here's some comments w.r.t. draft11, rick

Generically, I think the only effects on the client of "tight" vs "loose"
coupling is:
Loose coupling (when doing I/O on storage server):
- client uses synthetic uid/gid and anonymous stateid
- *** when fenced off, client sees NFS4ERR_ACCESS reply to I/O
Tight coupling (when doing I/O on storage server):
- client uses same uid/gid as for MDS for the file and ffds_stateid
- *** when fenced off, client sees NFS4ERR_BAD_STATEID reply to I/O

The "***" cases aren't explicitly spelled out in the draft. It might be nice
to have something like this near the beginning of the document, so that client
implementors aren't confused by the various discussions of "loose" vs "tight"
coupling.

Now, here's some things I spotted in draft-11.
> 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.
Spelling of occurance as noted before, plus..
I think that this needs to be changed to apply to both loose and tight
couplings too? (line 527-530 in the .txt file)
>   case that there is loose coupling is in effect.  If
>   ffdv_tightly_coupled is not set, then the client MUST commit writes
>   to the storage devices for the file before sending a LAYOUTCOMMIT to
>   the metadata server.  I.e., the writes MUST be committed by the
>   client to stable storage via issuing WRITEs with stable_how ==
...
>2.2.  Fencing Clients from the Storage Device
>
>   With loosely coupled storage devices, the metadata server uses
>   synthetic uids and gids for the data file, where the uid owner of the
>   data file is allowed read/write access and the gid owner is allowed
>   read only access.  As part of the layout (see ffds_user and
>   ffds_group in Section 5.1), the client is provided with the user and
>   group to be used in the Remote Procedure Call (RPC) [RFC5531]
>   credentials needed to access the data file.  Fencing off of clients
>   is achieved by the metadata server changing the synthetic uid and/or
>   gid owners of the data file on the storage device to implicitly
>   revoke the outstanding RPC credentials.
It might be nice to add that the client will receive a NFS4ERR_ACCESS reply
to I/O operations done against the storage server for the loosely coupled case?
...
>   With tightly coupled storage devices, the metadata server sets the
>   user and group owners, mode bits, and ACL of the data file to be the
>   same as the metadata file.  And the client must authenticate with the
>   storage device and go through the same authorization process it would
>   go through via the metadata server.  In the case of tight coupling,
>   fencing is the responsibility of the control protocol and is not
>   described in detail here.  However, implementations of the tight
>   coupling locking model (see Section 2.3), will need a way to prevent
>   access by certain clients to specific files by invalidating the
>   corresponding stateids on the storage device.
As above, it might be nice to clarify that the client will receive a
NFS4ERR_BAD_STATEID for the tight coupled case?
...
>      strongly coupled.  They would use a back-end control protocol to
I think David N. mentioned this before, but I think "strongly" should be
"tightly"?
...
>   F_FLAGS_NO_IO_THRU_MDS:  can be set to indicate that the client
>      SHOULD not send I/O operations to the metadata server.  I.e., even
>      if the client could determine that there was a network diconnect
>      to a storage device, the client SHOULD not try to proxy the I/O
>      through the metadata server.
Although I'll let the IETF guys debate the correct use of SHOULD, it seems
rather strong here, given that it is "at best a hint" as described here:
>5.1.2.  Client Interactions with FF_FLAGS_NO_IO_THRU_MDS
>
>   Even if the metadata server provides the FF_FLAGS_NO_IO_THRU_MDS,
>   flag, the client can still perform I/O to the metadata server.  The
>   flag is at best a hint.  The flag is indicating to the client that
...
>   data strucures are built on concepts introduced in NFSv4.2, the
Spelling of structures.
...
>13.  Recalling a Layout
>
>   While Section 12.5.5 of [RFC5661] discusses layout type independent
>   reasons for recalling a layout, the flexible file layout type
>   metadata server should recall outstanding layouts in the following
>   cases:
>
>   o  When the file's security policy changes, i.e., Access Control
>      Lists (ACLs) or permission mode bits are set.
I don't think this applies to the "tightly coupled" case, if the server
propagates the ACL, perm changes to the storage server?
Same comment applies to parts of:
>15.  Security Considerations
  third para.
>   devices.  When the metadata server receives a request to change a
>   file's permissions or ACL, it SHOULD recall all layouts for that file
>   and then MUST fence off any clients still holding outstanding layouts
>   for the respective files by implicitly invalidating the previously
>   distributed credential on all data file comprising the file in

________________________________________
From: nfsv4 <[e-mail]> on behalf of Thomas Haynes <[e-mail]>
Sent: Tuesday, July 18, 2017 6:06:16 AM
To: [e-mail]
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-flex-files-11.txt

This has the FF_FLAGS_WRITE_ONE_MIRROR and the fixed IANA considerations.


> On Jul 18, 2017, at 12:04 PM, [e-mail] wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network File System Version 4 of the IETF.
>
>        Title           : Parallel NFS (pNFS) Flexible File Layout
>        Authors         : Benny Halevy
>                          Thomas Haynes
>       Filename        : draft-ietf-nfsv4-flex-files-11.txt
>       Pages           : 40
>       Date            : 2017-07-18
>
> Abstract:
>   The Parallel Network File System (pNFS) allows a separation between
>   the metadata (onto a metadata server) and data (onto a storage
>   device) for a file.  The flexible file layout type is defined in this
>   document as an extension to pNFS which allows the use of storage
>   devices in a fashion such that they require only a quite limited
>   degree of interaction with the metadata server, using already
>   existing protocols.  Client side mirroring is also added to provide
>   replication of files.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-nfsv4-flex-files-11
> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-flex-files-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-flex-files-11
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4