From: Benny Halevy <bhalevy@tonian.com>
To: tigran.mkrtchyan@desy.de, Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: Session timeout on RHEL6.2
Date: Sun, 25 Dec 2011 06:37:44 +0200 [thread overview]
Message-ID: <4EF6A898.2010207@tonian.com> (raw)
In-Reply-To: <CAGue13pSKnxNK_UWnh0KXz_w-CbeWQjmDS1H7ZBVMRiV25JqmQ@mail.gmail.com>
On 2011-12-21 22:11, Tigran Mkrtchyan wrote:
> On Wed, Dec 21, 2011 at 2:57 PM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
>> On Wed, 2011-12-21 at 10:24 +0100, Tigran Mkrtchyan wrote:
>>> Dear friends,
>>>
>>> We are observing strange behavior with RHEL 6.2:
>>>
>>> Our the server lease time is 90 seconds. I can see that client
>>> sends SEQUENCE every 60 sec. And this is for some hours ( ~8 ).
>>> At some point client sends SEQUENCE after 127 seconds and
>>> gets, as expected, EXPIRED.
>>
>> Why shouldn't the client be allowed to let the lease expire if nothing
>> is using that filesystem?
>>
>>> I this point I have to blame myself.
>>> Client comes with EXCHANGE_ID using the same clientid.
>>> We did not garbage collected clientid internally as this happens after
>>> 2*LEASE_TIME
>>> and return EXPIRE. This ping-pong never ends.
>>>
>>> This is probably mostly a bug on my side. Nevertheless we never observed late
>>> SEQUENCE with kernel > 2.6.39. A short packet dump attached.
>>>
>>> I can open bug at RHEL if required.
>>
>> I wouldn't consider that a bug.
>
> As I said, there is a bug in exchange_id processing ( case 3 ) on my
> side. But to me it's sounds strange that client after more than 8
> hours of sending only sequence decided to send one of them later than
> lease time. Especially, that we did not have it with other kernels.
I'm inclined to agree. The client can let the lease expire for sure
and that's not a bug but the fact that the client sent the SEQUENCE operation
after the lease had expired indicates it might not be aware of that fact
and that seems to be a client bug.
That said, I don't think that letting the lease expire when the client is idle
is the most polite thing to do. Why let the server clean up after the client
and revert to possibly un-optimized recovery paths rather than orderly
destruction of the state by the client?
Benny
>
> Anyway, we will update our server tomorrow with bugfix.
>
> Tigran.
>
>>
>> Trond
>> --
>> Trond Myklebust
>> Linux NFS client maintainer
>>
>> NetApp
>> Trond.Myklebust@netapp.com
>> www.netapp.com
>>
next prev parent reply other threads:[~2011-12-25 4:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 9:24 Session timeout on RHEL6.2 Tigran Mkrtchyan
2011-12-21 13:57 ` Trond Myklebust
2011-12-21 20:11 ` Tigran Mkrtchyan
2011-12-25 4:37 ` Benny Halevy [this message]
2011-12-25 9:47 ` Trond Myklebust
2011-12-25 12:03 ` Benny Halevy
2011-12-25 13:25 ` Trond Myklebust
2011-12-29 19:20 ` Tigran Mkrtchyan
2011-12-30 1:03 ` Myklebust, Trond
2011-12-30 11:27 ` Tigran Mkrtchyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF6A898.2010207@tonian.com \
--to=bhalevy@tonian.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tigran.mkrtchyan@desy.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.