From: Neil Brown <neilb@cse.unsw.edu.au>
To: Fredrik Tolf <fredrik@dolda2000.com>
Date: Thu, 27 Nov 2003 10:42:47 +1100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16325.14967.248703.483363@notabene.cse.unsw.edu.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6 nfsd troubles - stale filehandles
In-Reply-To: message from Fredrik Tolf on Wednesday November 26
References: <16325.11418.646482.223946@pc7.dolda2000.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1354
Lines: 38

On Wednesday November 26, fredrik@dolda2000.com wrote:
> Hi!
> 
> I'm running my NFSv3 server at home on a 2.6 kernel, and it seems to
> have some issues, to say the least. The clients sporadically get stale
> handle errors, and I don't really know how to debug it.

I'll see if I can help.

I suspect that if you add the "no_subtree_check" export option the
problem will go away.  If you could confirm that, and then set it back
to "subtree_check" so we can keep hunting, that would be good.

Next, some better tracing.
The Linux NFS client will never re-try a filehandle that it thinks is
stale, so the tracing you did doesn't actually show any access of the stale
filehandle. 
So you need to have tracing on when the filehandle goes stale.

If you could:

  echo 2 >  /proc/sys/sunrpc/nfsd_debug 

and then try to create a stale file/directory, then the trace produced
by that could well be helpful.

Finally, when you have create a stale filehandle and got a good trace,
could you send it to me and include an
   ls -l
for the bad file/directory and every parent up to the export point.

Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/