Re: [nfsv4] (belated) copy of my review of draft-ietf-nfsv4-layout-types-03 (part 3)

[Thomas Haynes <[e-mail]>]

Here is part 3:

On Jul 16, 2015, at 4:21 PM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:


Implementations in Existing Layout Types

Some issues to address:

  *   The section title needs to be changed to reflect the fact that what is being described is primarily how the layout types are specified.  If implementations are described, those implementations have to match the specification.

Done

  *   It needs to be stated that the description of block and object layout are not normative since this document does not update RFC5663 and RFC5664.

Done

  *   You might also choose to state that the description of the files layout type is not normative, i.e. that you are only updating chapter 12 of RFC5661 and not chapter 13.

Done


We also have a potential issue for all of the mapping type regarding the potential interaction between open deny modes and use of anonymous stateids.  The issue is similar to mandatory byte-range locking but I can't recall its being addressed directly.


The fun never ends….



File Layout Type

I suggest replacing the first sentence by the following:


Because the storage protocol is a subset of NFSv4.1, the semantics of the File Layout Type comes closest to the semantics of NFSv4.1 in the absence of pNFS.


In the second sentence, suggest replacing "stateid" by "stateid and principal" since many of the validations mentioned relate to authorization.

Also in the second sentence, suggest replacing "was" by "were".

Suggest deleting "in the absence of pNFS" from the second sentence and adding the following sentence:

The same set of validations apply whether pNFS is in effect or not.

Ack to all of the above

Okay, the last two sentences now seem very redundant:

      Because the storage protocol is a subset of NFSv4.1, the semantics
      of the file layout type comes closest to the semantics of NFSv4.1
      in the absence of pNFS.  In particular, the stateid and principal
      used for I/O MUST have the same effect and be subject to the
      same validation on a data server as it would if the I/O were
      being performed on the metadata server itself.  The same set of
      validations apply whether pNFS is in effect or not.





I have some issues that relate to material that starts in the second paragraph, proceeds through the bulleted items and goes on into the third (non-bulleted) paragraphs.  Some issues:

  *   As far as I can see, chapter 13 of RFC5661 does not say "SHOULD" about these validations with regard to the file layout type.

1) client holds a valid layout,

page 329:

   The iomode need not be checked by the data servers when clients
   perform I/O.  However, the data servers SHOULD still validate that
   the client holds a valid layout and return an error if the client
   does not.

2) client I/O matches the layout iomode, and,

(note, see the “need not” above in 1)

page 328:

   the server to return a layout enabling the client to do so.  As such,
   the client SHOULD set the iomode based on its intent to read or write
   the data.  The client may default to an iomode of LAYOUTIOMODE4_RW.

3) client does not go out of the byte ranges,

page 285

   client.  If a storage device receives an I/O request for a byte-range
   for which the client does not hold a layout, the storage device
   SHOULD reject that I/O request.  Note that the act of modifying a

Granted this is Chapter 12, but there is no mention of this in Chapter 13.



  *   If the data server is not enforcing these validations, then who is?  I don't see how the semantic requirements for NFSv4 as a whole can be enforced if nobody is requiring that appropriate layouts be validly held by the client when IO is done to data servers? If this is not a MUST for the data server then I think it it has to be a MUST for clients.

It COULD be a requirement for data servers, but it CAN NOT be a requirement for storage devices.



  *   While section 13.6 of RFC5661 does have the following MUST. it does not mention appropriateness of ranges or modes.  Also, since the data server must reject the IO, it isn't clear why the server MUST NOT issue it.

As described in Section 12.5.1<https://tools.ietf.org/html/rfc5661#section-12.5.1>, a client MUST NOT send an I/O to a data server for which it does not hold a valid layout; the data server MUST reject such an I/O.

That directly conflicts with Sections 13.8.




With regard to the last paragraph:

  *   It is only the data filehandle that ensures that the client has a valid layout for the the I/O being performed. The mention of the stateid confuses things since this only used to ensure proper locking.
  *   Suggest replacing "fenced off for" by "fenced off from"
  *   If you invalidate a stateid, you are not typically fencing ff a client. Rather you are fencing off a particular owner or open file. Only in the case of a delegation stateid are you fencing off a client.

Ask 99.9999% of the people who have read the spec (or assume they understand pNFS) and they would use the term of fencing off the client.

I am heartened by the fact that 6 9s of reliability is wrong. :-)

And for completeness sake, fencing off a lock stateid would mean only fencing off a lock owner.


Okay, I’ve pulled out a “whilst”, but I separated the two issue.

It appears that because the files layout is able to cleanly deal with locking issues as well as security/authorization issues, they wind up confused here. It appears that you have to make a decision to clearly discuss locking issues as well as security issues. If you do, then. as in this case, you need to clearly separate locking considerations from authorization ones when necessary.


Hand waving that I have done, expecting to be corrected if I have not. :-0



Block Layout Type

With regard to the phrase "at the granularity of individual hosts, not individual blocks", this conflates two ways in which SAN access control is coarser-grained than that for NAS devices.  It seems that you have to decide which of the following you want to say:

  *   at the granularity of LUNs rather than of individual files or blocks. [object granularity]
  *   at the granularity of hosts rather than of principals. [subject granularity]

TBD


With regard to the last sentence of the first paragraph:

  *   Suggest replacing "is very careful to define" by "specifies”.

Heh, the first time your replacement text has been shorter than what it replaces!


  *   Since "SHOULD NOT" does not appear to to meet the definition in RFC2219, it should appear in quote marks in this document.

The usage is directly from RFC 5663.

I’ve fixed this by quoting the text verbatim.




  *   A suitable paraphrase of the intent of the last clause might be "use of the pNFS Block Layout Type is not appropriate”.

see above

Suggest the following replacement for the second paragraph:


As a result of these granularity issues, the security burden has been shifted from the storage devices to the client.  Those deploying implementations of this layout type need to be sure that  the client implementation can be trusted  This is not a new sort of requirement in the context of SAN protocols.  In such environments,  the client is expected to provide block-based protection.


Ack


With regard to the third paragraph:

  *   In the first sentence, suggest replacing "implication" by "shift of the burden”

Ack


  *   As ACLs relate  to security, if they need to be mentioned explicitly (which I don't think is necessary), it should be done in the previous paragraph.

Taken out


  *   In the second sentence, suggest replacing "might not be" by "is not”.

Ack


  *   The third sentence is confusing.  Suggest the following replacement:

For example, the server may use a layout iomode allowing reading to enforce a mandatory read-only lock,  In such cases, the client has to support that use by not sending WRITEs to the storage devices.

  *   In the fourth sentence:
     *   Suggest replacing "basic" by "fundamental".
     *   Suggest replacing "can be treated" by "is treated by this layout type".
     *   Suggest ending this sentence after "dumb disk" and proceeding with a new sentence like the following:

Once the client has access to the storage device, it is able to perform both READ and WRITE I/O to the entire storage device.

  *   The fifth sentence is a good summary but it needs something additional to "close the deal".  Suggest:

Therefore, the client is required to provide that enforcement.

Ack to the above



With regard to the last paragraph, suggest the following replacement:


In the context of client fencing upon revocation Of a layout, the abovementioned 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.



Took an edited version