Re: [PATCH 1/9] Revert "pnfs-submit: wave2: remove forgotten layoutreturn struct definitions"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Benny,

On Thu, Dec 16, 2010 at 3:26 PM, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote:
> On 2010-12-15 22:24, Trond Myklebust wrote:
>> On Wed, 2010-12-15 at 14:31 -0500, Trond Myklebust wrote:
>>> On Wed, 2010-12-15 at 20:51 +0200, Benny Halevy wrote:
>>
>>>> Eventually, when CB_LAYOUTRECALL is clear to go sending the LAYOUTRETURN
>>>> or replying with CB_NOMATCHING_LAYOUT (assuming no I/O error to report
>>>> for pnfs-obj) should be equivalent [note: need errata to clarify the
>>>> resulting stateid after NOMATCHING_LAYOUT].
>>>> Is this the serialization "crap" you're talking about?
>>>> What makes checking the conditions for returning NFS4ERR_DELAY to
>>>> CB_LAYOUTRECALL so different from implementing a barrier and doing the
>>>> returns asynchronously with the CB_LAYOUTRECALL?
>>>
>>> "CB_LAYOUTRECALL request processing MUST be processed in "seqid" order
>>> at all times." (section 12.5.3).
>>>
>>> In other words, you cannot just 'do the returns asynchronously': the
>>> CB_LAYOUTRECALL requests are required by the protocol to be processed in
>>> order, which means that you must serialise those LAYOUTRETURN calls to
>>> ensure that they all happen in the order the wretched server expects.
>>
>> BTW: one consequence of the way the protocol was written is that you
>> can't just throw out a LAYOUTRETURN for the entire file if the server
>> just recalls a segment. Instead, you have to first return the segment,
>> then send the LAYOUTRETURN for the entire file.
>>
>
> It is true that the protocol requires the return of the exact recalled range
> but why can't the client do return the whole file before returning the recalled
> range?
Just for clarification, do you mean that after client returns more
than server recalls, clients still has to do an echoing LAYOUTRETURN?
It is barely overhead...
Why would server require some behavior like that?

>
>> That part of the protocol is just one insane idea after another...
>>
>
> This was done to ensure that the server and client are in-sync after a
> CB_LAYOUTRECALL. ÂI agree that returning the whole layout thus resetting
> the layout state achieves the same goal and we should consider allowing it
> in the next version.
>
> Benny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
>



-- 
Thanks,
-Bergwolf
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux