[nfsv4] LAYOUTCOMMIT discussion

[<[e-mail]>]

I'd like to make sure we pursue this and come to some sort of conclusion
or at least make progress toward a solution.

One problem with LAYOUTCOMMIT description is that the text is very
block-oriented.  That's a result of the fact that 80% of the
functionality is appropriate to block layouts but it needs to explain,
what is and what isn't done in the case of file layouts.  A particular
example is loca_last_write_offset.  This is required because for block
because you may write one block of a file when only one byte is part of
the file.  But, for file, the DS knows the last offset and allowing you
to specify a possibly invalid one is not appropriate. 

But as far as the issue about when and if to use it, the troubling part
is the following last paragraph of section 13.10.

   The NFSv4.1 protocol only provides close-to-open file data cache
   semantics;

This is NOT what the v4.1 protocol provides.  It is up to the client to
determine if it caches data and many clients, don't for good reasons.
As far as the protocol goes, leaving pNFS aside, if you do a write the
change attribute will change and it supposed do. 

   meaning that when the file is closed, all modified data is
   written to the server.  When a subsequent OPEN of the file is done,
   the change attribute is inspected for a difference from a cached
   value for the change attribute.  For the case above, this means that
   a LAYOUTCOMMIT will be done at close (along with the data WRITEs) and
   will update the file's size and change attribute.  Access from
   another client after that point will result in the appropriate size
   being returned.

"a LAYOUTCOMMIT 'will be done' at close".  Not MUST or SHOULD.  And the
text suggests that the client adds this op as opposed to it being part
of CLOSE, but it isn't absolutely clear about that.

The reason that it is better for this to be automatic part of CLOSE, is
that there are going to be instances in which the file is closed when no
CLOSE is done (e.g. lease expiration), and the server had better do a
LAYOUTCOMMIT at that point or everything is a mess.

So here is my proposal for what should be written in this place:

    Many uses of the NFSv4.1 protocol are based on close-to-open
    caching semantics and it is a requirement that the modify time
    is updated frequently enough to support this.  In the case of
    the file layout type, when there have been writes done through
    a file layout on a file being closed, the client SHOULD do a 
    LAYOUTCOMMIT after completion of all the writes and before the
    CLOSE.  This will ensure that the change attribute and file size
    are updated appropriately so that access from another client
    after that point will result in the appropriate attributes
    being returned.

    When a file open for write is closed a result of a lease expiration,

    and the client has a layout for that file, the server must perform 
    the equivalent of a LAYOUTCOMMIT before closing the file, typically
    by fetching current attributes from the DS, to ensure that the
file's 
    attributes are properly updated.  When a lease expiration involves
    multiple files open for write for which there are associated
    layouts, the server is free to fetch attributes for multiple
    file from a DS in a single control protocol request. 
    
    When a lease is expired but the close does not occur immediately 
    the server still SHOULD perform the equivalent of a LAYOUTCOMMIT 
    at the point of lease expiration.

    In many applications, there are files that essentially are never
    closed.  In order to provide more meaningful attribute values in
    such environments, the server SHOULD ensure that the propagation
    of attributes (size, change, etc.) is done at least every lease
    period.  Because attribute updates for many file from a single DS 
    could be gathered in a single request, the resources to do this
    not very large.

 Comments?