Subject: RE: [nfsv4] Proposal for adding reclaim bit to pNFS COMMITLAYOUT

From: [email-masked]
Date: Wed, 15 Feb 2006 15:17:39 -0500

Benny---
See my comments below... 

From: Benny Halevy [mailto:[email-masked]] :
> 
> [email-masked] wrote:
> 
> >Benny---
> >
> 
<snip>
> 
> >On the other hand, this bit of logic is very subtle. It
> >requires the server to make an inference about the client state
> >based on the server's own state (or lack thereof).  How sure are
> >we that this reasoning is valid?  Under all circumstances?  I
> >wouldn't want to bet my data on it.  Making the "reclaim" aspect
> >of the LAYOUTCOMMIT (or LAYOUTRETURN) request explicit by using
> >a flag simplifies the server's job and doesn't cost much.
> >
> >Short summary:  I'm ok with adding a "reclaim" flag to LAYOUTRETURN
> >to meet your requirement, although I wonder whether using RECLAIM_
> >COMPLETE might be a more efficient way to go.  I also think that,
> >whatever we do, we should keep the "reclaim" flag explicit.
> >  
> >
> I assumed that the server will deny new LAYOUTGETs during the grace 
> period so every LAYOUTCOMMIT or LAYOUTRETURN must refer to 
> layouts that 
> were issued before the reboot.  If the server will serve 
> LAYOUTGETs, for 
> example, when they do not conflict with any outstanding 
> layout (assuming 
> the server has persistent knowledge of which layouts are outstanding 
> from before the reboot), then yes, I agree with what you say 
> above that 
> a reclaim bit will make the server's life a bit easier and 
> safer. Adding 
> a reclaim field to LAYOUTRETURN will satisfy both the 
> simplicity/sanity 
> check requirements and will allow cleanly returning layouts 
> in the grace 
> period.  I'm inclined not to rely solely on RECLAIM_COMPLETE since I 
> don't want the server to trust the client on this issue in 
> such a broad 
> manner. I'd rather rely on specific, positive indication from 
> the client.
> 

Ok, so it sounds like we are in agreement:  there is a need to add
a reclaim field to the LAYOUTRETURN operation.  

Now assuming you are ok with the text of the reclaim/LAYOUTCOMMIT
proposal that I send out later today (it will be updated to reflect
Garth's comments), how do you feel about modifying the proposal text
to cover the LAYOUTRETURN reclaim operation?

I'm asking you because:
1) I'm not as familiar with the motivation for the change as you, and
2) I'm going on vacation on Friday!  ;)

-Steve

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

---

From: Benny Halevy <[email-masked]>
Date: Wed, 15 Feb 2006 22:38:05 +0200

>2) I'm going on vacation on Friday!  ;)
Sure. Will do.

Benny

---

From: Garth Goodson <[email-masked]>
Date: Wed, 15 Feb 2006 12:49:06 -0800

Benny Halevy wrote:
>>> period so every LAYOUTCOMMIT or LAYOUTRETURN must refer to layouts 
>>> that were issued before the reboot.  If the server will serve 
>>> LAYOUTGETs, for example, when they do not conflict with any 
>>> outstanding layout (assuming the server has persistent knowledge of 
>>> which layouts are outstanding from before the reboot), then yes, I 
>>> agree with what you say above that a reclaim bit will make the 
>>> server's life a bit easier and safer. Adding a reclaim field to 
>>> LAYOUTRETURN will satisfy both the simplicity/sanity check 
>>> requirements and will allow cleanly returning layouts in the grace 
>>> don't want the server to trust the client on this issue in such a 
>>> broad manner. I'd rather rely on specific, positive indication from 
>>> the client.
>>>
>>>   
>>
>>

Just make sure that the text changes are layout type independent.  I 
wouldn't think more than a paragraph or so is needed in addition to the 
changes to the LAYOUTRETURN op description.

-Garth