> On Nov 18, 2016, at 15:52, bfields@xxxxxxxxxxxx wrote:
>
> On Thu, Nov 17, 2016 at 10:43:58PM +0000, Trond Myklebust wrote:
>> On Thu, 2016-11-17 at 17:27 -0500, Olga Kornievskaia wrote:
>>> On Thu, Nov 17, 2016 at 5:15 PM, Trond Myklebust
>>> <trondmy@xxxxxxxxxxxxxxx> wrote:
>>>> What's the alternative? Assume the client pre-emptively bumps the
>>>> seqid
>>>> instead of retrying, then the user presses Ctrl-C again. Repeat a
>>>> few
>>>> more times. How do I now resync the seqids between the client and
>>>> server other than by trashing the session?
>>>
>>> I don't see any alternatives than to reset in that case. But I think
>>> it's better then the possibility of accidentally opening a wrong
>>> file?
>
> Remind me why you can't continue resending after the Ctrl-C? (I thought
> this was already done for some lock and other cases?)
We’d have to do it for all RPC calls, which means they would all have to be converted to not use the stack. The resulting behaviour would also be confusing, as operations would complete outside of locking rules etc. So, for instance, you would be seeing successfully looked up files mysteriously disappearing as the asynchronous unlink() operation that was interrupted completes, or directories mysteriously getting renamed.
>
>> They sound equally bad to me which is why I'm not understanding how a
>> server would fail to implement some minimal form of false retry
>> checking.
>> The Linux NFSv3 DRC will, for instance, checksum at least some part of
>> the RPC arguments for _all_ RPC calls. Most NFSv4.x clients will only
>> ask that you checksum the non-idempotent RPC calls, which significantly
>> cuts down on the calculation overhead.
>
> I'll look at adding checksumming, it shouldn't be hard.
Thanks.
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
