linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: "Dr. J. Bruce Fields" <bfields@fieldses.org>
Cc: Harry Edmon <harry@uw.edu>, Chuck Lever <chuck.lever@oracle.com>,
	linux-nfs@vger.kernel.org
Subject: Re: 2.6.38.6 - state manager constantly respawns
Date: Fri, 20 May 2011 14:36:56 -0400	[thread overview]
Message-ID: <1305916616.14253.1.camel@lade.trondhjem.org> (raw)
In-Reply-To: <1305913963.12712.6.camel@lade.trondhjem.org>

On Fri, 2011-05-20 at 13:52 -0400, Trond Myklebust wrote: 
> On Fri, 2011-05-20 at 13:26 -0400, Dr. J. Bruce Fields wrote: 
> > On Fri, May 20, 2011 at 09:20:47AM -0700, Harry Edmon wrote:
> > > On 05/16/11 13:53, Dr. J. Bruce Fields wrote:
> > > >Hm, so the renews all have clid 465ccc4d09000000, and the reads all have
> > > >a stateid (0, 465ccc4dc24c0a0000000000).
> > > >
> > > >So the first 4 bytes matching just tells me both were handed out by the
> > > >same server instance (so there was no server reboot in between); there's
> > > >no way for me to tell whether they really belong to the same client.
> > > >
> > > >The server does assume that any stateid from the current server instance
> > > >that no longer exists in its table is expired.  I believe that's
> > > >correct, given a correctly functioning client, but perhaps I'm missing a
> > > >case.
> > > >
> > > >--b.
> > > I am very appreciative of the quick initial comments I receive from
> > > all of you on my NFS problem.   I notice that there has been silence
> > > on the problem since the 16th, so I assume that either this is a
> > > hard bug to track down or you have been busy with higher priority
> > > tasks.  Is there anything I can do to help develop a solution to
> > > this problem?
> > 
> > Well, the only candidate explanation for the problem is that my
> > assumption--that any time the server gets a stateid from the current
> > boot instance that it doesn't recognize as an active stateid, it is safe
> > for the server to return EXPIRED--is wrong.
> > 
> > I don't immediately see why it's wrong, and based on the silence nobody
> > else does either, but I'm not 100% convinced I'm right either.
> > 
> > So one approach might be to add server code that makes a better effort
> > to return EXPIRED only when we're sure it's a stateid from an expired
> > client, and see if that solves your problem.
> > 
> > Remind me, did you have an easy way to reproduce your problem?
> 
> My silence is simply because I'm mystified as to how this can happen.
> Patching for it is trivial (see below).
> 
> When the server tells us that our lease is expired, the normal behaviour
> for the client is to re-establish the lease, and then proceed to recover
> all known stateids. I don't see how we can 'miss' a stateid that then
> needs to be recovered afterwards...

Bruce,

If the clientid expired, is it possible that the server may have handed
out the same numerical short clientid to someone else and that explains
why the RENEW is succeeding?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com


  reply	other threads:[~2011-05-20 18:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16 18:40 2.6.38.6 - state manager constantly respawns Harry Edmon
2011-05-16 18:45 ` Chuck Lever
2011-05-16 19:12   ` Harry Edmon
2011-05-16 19:22     ` Chuck Lever
2011-05-16 19:36       ` Harry Edmon
2011-05-16 19:43         ` Trond Myklebust
2011-05-16 19:48           ` Harry Edmon
2011-05-16 19:54             ` Trond Myklebust
2011-05-16 20:20               ` Dr. J. Bruce Fields
2011-05-16 20:53                 ` Dr. J. Bruce Fields
2011-05-20 16:20                   ` Harry Edmon
2011-05-20 17:26                     ` Dr. J. Bruce Fields
2011-05-20 17:52                       ` Trond Myklebust
2011-05-20 18:36                         ` Trond Myklebust [this message]
2011-05-20 18:59                           ` Dr. J. Bruce Fields
2011-05-20 19:15                             ` Trond Myklebust
2011-05-20 19:32                               ` Dr. J. Bruce Fields
2011-05-20 18:47                         ` Dr. J. Bruce Fields
2011-05-20 18:50                           ` Bryan Schumaker
2011-05-20 19:29                         ` Harry Edmon
2011-05-20 19:39                           ` Andy Adamson
2011-05-20 19:40                           ` Trond Myklebust
2011-05-20 19:44                             ` Harry Edmon
2011-05-20 20:11                               ` Trond Myklebust
2011-05-20 20:23                                 ` Harry Edmon
2011-05-20 20:27                                   ` Trond Myklebust
2011-05-20 18:35                       ` Harry Edmon
2011-05-16 20:21           ` Chuck Lever
2011-05-16 20:33             ` Trond Myklebust
     [not found]               ` <1305578007.19725.24.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
2011-05-16 20:37                 ` Harry Edmon

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=1305916616.14253.1.camel@lade.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=harry@uw.edu \
    --cc=linux-nfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).