Re: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types

[Thomas Haynes <[e-mail]>]

> On Aug 16, 2017, at 2:04 AM, Christoph Hellwig <[e-mail]> wrote:
> 
> I don't have a whole lot of time to spare, so this is a very
> narrow review with the focus on interactions with the scsi
> and rdma layout types.
> 
> The first thing I noticed is that section 3 claims:
> 
> "There have been no published specifications for control protocols as yet."
> 
> which I don't think is true any more.  The SCSI layout fully specifies
> the interaction between the MDS and the storage device, so it should
> be considered to include a control protocol.

RFC8154 doesn’t quite say that:

   The Server to Storage System protocol, called the "Control Protocol",
   is not of concern for interoperability, although it will typically be
   the same SCSI-based storage protocol.

I read that to say that it is possible for someone to implement the SCSI
layout without using the SCSI-based storage protocol. 

Going to the new terms:

  control communication requirements:  are for a layout type the
      details regarding information on layouts, stateids, file metadata,
      and file data which must be communicated between the metadata
      server and the storage devices.

   control protocol:  is the particular mechanism that an implementation
      of a layout type would use to meet the control communication
      requirement for that layout type.  This need not be a protocol as
      normally understood.  In some cases the same protocol may be used
      as a control protocol and data access protocol.

I would say that RFC8154 does fully meet the "control communication requirements”.

But based on the sentence above, I see a SHOULD on the use of the
SCSI-based storage protocol as a control protocol and not a MUST.

And given that RFC5663 also states:

   While the Server to
   Storage System protocol, called the "Control Protocol", is not of
   concern for interoperability here, it will typically also be a
   block/volume protocol when clients use block/ volume protocols.

and we don’t consider that layout type to have a control protocol.


> 
> Note that in terms of specifications the it only uses SCSI and thus
> the storage protocol, but it uses different features in the SCSI
> specifications that are designed to be a control protocol, and the
> particular way in the MDS has to use SCSI persistent reservations
> could be considered a protocol by itself.  So the paragraph below
> about loose coupling doesn't really apply in this case either.

I think you are arguing that since RFC5663 did not address directly
how the mds would fence the client and RFC8154 does, that
a full control protocol does exist in RFC8154.  And that the
sentence in question should read:


   The Server to Storage System protocol, called the "Control Protocol",
   is the same SCSI-based storage protocol.


> 
> All of that is pretty editorial though as it doesn't change any of
> the fundamentals of the section.
> 
> I'm not sure what the point of
> 
> "Whether the metadata server allows access over other protocols
> (e.g., NFSv3, Server Message Block (SMB), etc) is strictly an
> implementation choice, just as it is in the case of any other
> (i.e., non-pNFS-supporting) NFSv4.1 server."
> 
> is.  While the statement is true nothing in NFS talks about
> cross-protocol access to servers, so I don't think it matters.
> 

The point I was trying to make is that if the client wants
access to the storage devices by a non-supported layout type,
then it has to access the data through the mds.

But having thought about it, I don’t see the value of leaving that
sentence in place.


> 
> Section 4.1 probably needs an update to include the SCSI layout
> given that it claims to document the existing layout types.

This was taken care of earlier by changing the title to:

4.  Specifications of Original Layout Types



>  The
> block layout section is more or less valid for the SCSI layout
> as well, so I would suggest to handle the SCSI layout in the
> same section.
> 
> Another aspect that might be worth mentioning somewhere is
> that layouts may revoke access to the whole storage device
> for fencing when a layout recall is not acted upon.

I thought this covered that?

   In the context of fencing off of the client upon revocation of a
   layout, these limitations come into play again, i.e., the granularity
   of the fencing can only be at the host/logical-unit level.  Thus, if
   one of a client's layouts is revoked by the server, it will
   effectively revoke all of the client's layouts for files located on
   the storage units comprising the logical volume.  This may extend to
   the client's layouts for files in other file systems.  Clients need
   to be prepared for such revocations and reacquire layouts as needed.



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