Subject: Re: [nfsv4] return_on_close hint in LAYOUTGET result

From: Benny Halevy <[email-masked]>
Date: Mon, 09 Oct 2006 12:52:30 +0200

Issue 132 opened for this.

Tigran Mkrtchyan wrote:
> Hi Spencer,
>
> I guess it's has to be a mandatory flag, otherwise,
> we have to be prepared that a client ignores the flag, and have to
> invoke explicit CB_LAYOUTRECALL.
>   

You should always be prepared to recall the layout if you need to.
The intention of this flag is to optimize this case by saving a 
cb_layoutrecall
when the server knows in advance that it wants the layout back before the
file is closed. If the client does not do that, for any reason, the 
server should
explicitly recall the layout and only then it is mandatory for the client to
return it, otherwise the layout will be revoked.  I'd rather have only one
mandatory path that can lead to harsh sanctions against the client.

>
> Yet another point. Is it possible to add optional file attribute, let say:
>
> typedef nfstime4	fattr4_time_delay;
>
> which gives the client a hint for a next request on NFS4ERR_DALAY. If
> tape system is off-line, file may be unavailable for hours or even days,
> and there is no reason for a client to retry request every 30 seconds.
>
> Regards,
> 	Tigran.
>
>
>   
>> On Thu, Benny Halevy wrote:
>>     
>>> As discussed in Ann Arbor, I'm proposing to add a hint to the LAYOUTGET
>>> results structure that requests the client to return the layout before 
>>> closing the
>>> associated file.  This behavior was initially requested by DESY to optimize
>>> their application that uses the write layout only once and therefore, in 
>>> the absence
>>> of this flag will always recall the layout upon close after write.  In 
>>> the pnfs over
>>> objects case we also want all write layouts returned early, before the 
>>> file is closed
>>> and released at the server.  Since this behavior is server and iomode 
>>> specific and
>>> in our case may also be raid-level specific I propose to add the flag to 
>>> each
>>> returned layout rather than having a file or filesystem  attribute, a 
>>> mount option,
>>> or a layout driver policy.
>>>
>>>   struct LAYOUTGET4resok {
>>>           layout4            logr_layout;
>>> +         bool                return_on_close;
>>>   };
>>>       
>> Benny,
>>
>> Would you please create an issue for this and if there isn't dissent soon,
>> please provide the proposed text changes and assign to me.
>>
>> btw: I assume that since the title said "hint" that return_on_close
>> is advisory?
>>
>> Spencer
>>
>>     
> ________________________________________________________________________
> Tigran Mkrtchyan                               DESY, IT,
> [email-masked]                       Notkestrasse 85,
> Tel: + 49 40 89983946                          Hamburg 22607,
> Fax: + 49 40 89984429                          Germany.
>   

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

---

From: Benny Halevy <[email-masked]>
Date: Tue, 17 Oct 2006 14:51:04 +0200

I propose the following change for the return_on_close hint.

Please note that the additional result field was added before
logr_layout since layout4 contains a variable length opaque
field.

Benny

 16.43.3.  RESULT

    struct LAYOUTGET4resok {
+           bool               logr_return_on_close;
            layout4            logr_layout;
    };

@@ -21965,6 +21979,12 @@
    layout type specific protocol.  An iomode of either LAYOUTIOMODE_READ
    or LAYOUTIOMODE_RW must be returned.

+   The "logr_return_on_close" result field is a hint to the client to
+   return the layout before closing the file.  Servers that know at
+   layoutget time that the layout is going to be recalled when the file
+   is closed can set this field to true.  However, the server should be
+   ready to recall the layout at close time if needed.
+
    The format of the returned layout is specific to the underlying file
    system.  Layout types other than the NFSv4 file layout type should be
    specified outside of this document.

Benny Halevy wrote:
>>>> results structure that requests the client to return the layout 
>>>> before closing the
>>>> their application that uses the write layout only once and 
>>>> therefore, in the absence
>>>> of this flag will always recall the layout upon close after write.  
>>>> In the pnfs over
>>>> objects case we also want all write layouts returned early, before 
>>>> the file is closed
>>>> and released at the server.  Since this behavior is server and 
>>>> iomode specific and
>>>> in our case may also be raid-level specific I propose to add the 
>>>> flag to each
>>>> returned layout rather than having a file or filesystem  attribute, 
>>>> a mount option,