Subject: [nfsv4] setattr request and CB_SIZECHANGED

From: [email-masked]
Date: Tue, 7 Mar 2006 17:24:41 -0500

Hi All--

Just to follow up some discussion that we had on the
con-call a couple of weeks back... I want to talk about
the CB_SIZECHANGED callback and SETATTR.  The current
i-d is fairly vague about how to synchronize the processing
of the SETATTR and the CB_SIZECHANGED callback.  David
Black and I discussed it, and we believe that the right
way to go (at least from the block/volume perspective) is
to delay the actual processing of the SETATTR until all
clients with outstanding layouts have been notified about
the pending size change, and have had a chance to take
appropriate actions.  For block/volume clients, these
actions may include partial zeroing of the new end-of-file
block if the client holds a layout on it, and then committing
the updated layout back to the server.  Object and file
clients may have different actions that need to be taken.
In general however, it seems reasonable that the server
should only process the SETATTR if it is sure that the
new state information has been propagated to all the clients
that need it.

Our thinking is that we need some text in the i-d which
specifically states how SETATTR and CB_SIZECHANGED should
be synchronized.  Other thoughts?

-Steve

------------------------------------------------------------
Stephen Fridella                            ph: 508-305-8512
Principal Software Engineer                fax: 508-305-4803
EMC NAS Advanced Development         sfridell AT emc DOT com

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 7 Mar 2006 18:15:32 -0600

> be synchronized.  Other thoughts?

Not other thoughts but clarification of behavior.

How sure should the server be that the SETATTR is likely to
succeed before doing the CB_SIZECHANGED call?  Obviously
passing all checks up to the final change in size?  Seems
reasonable.

I assume that the server should return DELAY to the setattr
while it awaits the clients to sort out their details.
In that case, the client that instantiated the SETATTR may
not send the request again.  Does that change the behavior
you describe?

Spencer

---

From: Benny Halevy <[email-masked]>
Date: Wed, 08 Mar 2006 17:20:43 +0200

[email-masked] wrote:

>the updated layout back to the server.  
>
Writing to storage and committing layouts (without returning them?) 
seems to me well beyond the intended scope of CB_SIZECHANGED.  What's 
the state of any complete block in the layout beyond the new EOF after 
this call?  If the layout becomes invalid beyond the new EOF then I 
think it should be implicitly recalled rather than implying that as a 
side effect of CB_SIZECHANGED.
As an optimization, we may want to consider adding an optional 
"new_size" field to CB_LAYOUTRECALL that can provide a hint to the 
client not to bother flushing any dirty data beyond the new size but 
rather just drop it from their cache, and in addition, for block based 
layouts, the client must zero out the bytes from the new size up to the 
end of the corresponding block, if it has a layout covering that block 
(what happens if multiple clients hold a reference to this offset?  Is 
it always true they will point to different blocks on disk so they will 
never step on each other's toes?)

>Object and file