Subject: RE: [nfsv4] setattr request and CB_SIZECHANGED

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 8 Mar 2006 10:24:35 -0500

> 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.

I'm assuming you mean "explicitly recalled", in which case I
agree.

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]]
Sent: Wednesday, March 08, 2006 10:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] setattr request and CB_SIZECHANGED

[email-masked] wrote:

>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.  
>
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
>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
>  
>

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

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