Subject: [nfsv4] Issue 21: pnfs EOF handling

From: [email-masked]
Date: Tue, 27 Jun 2006 10:54:06 -0400

Hi all---
Here is my proposed text to address this issue.  The goal is to
clarify the server/client behavior around SETATTR and CB_SIZECHANGED.
Please send comments/corrections to the list.
-Steve

------------------------------------------------------------------

In section 14.4.2, replace the following paragraph:

Since client layout holders may be unaware of changes made to the
file's size, through LAYOUTCOMMIT or SETATTR, by other clients, an
additional callback/notification has been added for pNFS.
CB_SIZECHANGED is a notification that the metadata server sends to
layout holders to notify them of a change in file size.  This is
preferred over issuing CB_LAYOUTRECALL to each of the layout holders.

with the following text:

Since changes made to the file's size may affect the semantics of
layouts held by other clients, an additional callback/notification
has been added for pNFS.  CB_SIZECHANGED is a notification that the
metadata server sends to layout holders to notify them of a change
in file size.  Specifically, whenever a file is truncated by SETATTR,
the server MUST send CB_SIZECHANGED callbacks to each client that
holds a layout for any portion of the file falling at or beyond the
new end of file byte. Depending on the requirements of the storage
protocol the server MAY issue CB_LAYOUTRECALL callbacks for portions
of layouts which overlap or lie beyond the new end of file.  If so,
the CB_LAYOUTRECALL callback SHOULD follow the CB_SIZECHANGED
callback in the same compound callback operation. Moreover, the server
SHOULD NOT respond to the SETATTR request until each client has
responded to the CB_SIZECHANGED callback and completed any required
LAYOUTRETURN operations. Whenever the size of the file is extended
by either SETATTR or LAYOUTCOMMIT, the server MAY send CB_SIZECHANGED
callbacks to clients which hold layouts for the file.  The choice of
whether or not to send CB_SIZECHANGED in such circumstances is
dependent on the requirements of the storage protocol.

In section 28.4, replace the following paragraph:

The CB_SIZECHANGED operation is used to notify the client that the
size pertaining to the filehandle associated with "fh", has changed.
The new size is specified.  Upon reception of this notification
callback, the client should update its internal size for the file.
If the layout being held for the file is of the NFSv4 file layout
type, then the size field within that layout should be updated (see
Section 16.5).  For other layout types see Section 14.4.2 for more
details.

with the following text:

The CB_SIZECHANGED operation is used to notify the client that the
size pertaining to the filehandle associated with "fh", has changed.
The new size is specified.  Upon reception of this notification
callback,
the client SHOULD update its internal size for the file.  Depending on
the storage protocol used, the client may also need to update the states
of layouts it holds for the file which span the new end of file byte.
For example, if the layout being held for the file is of the NFSv4 file
layout type, then the size field within that layout should be updated
(see Section 16.5).  For other layout types, the layout-specific
specification will provide details of the updates that are required.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Garth Goodson <[email-masked]>
Date: Tue, 27 Jun 2006 13:50:46 -0700

> Please send comments/corrections to the list.
Is this too restrictive for some implementations (i.e., impose 
unnecessary delays when the backend system can handle the changes)?  My 
concern arises over the MUST send CB_SIZECHANGED and SHOULD NOT respond 
to the SETATTR until all responses have been received (I guess it is a 
SHOULD NOT rather than a MUST NOT).  Remind me why we need to wait for 
the CB replies.

I also want to bring up something else that Spencer brought up earlier. 
  It went something like this:

1) SETATTR that truncates file arrives
2) Server sends out CB_SIZECHANGED, and DELAY error to setattr caller
3) Setattr caller never retries SETATTR, but CB has been sent out

I'm not sure how to work around this.  Is this a problem -- or is it ok 
that the client can confuse other clients?

-Garth