From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: nfsd, rmtab, failover, and stale filehandles
Date: Fri, 7 May 2004 14:25:43 -0400
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <20040507182543.GA27341@fieldses.org>
References: <20040506185603.GM23287@polop.usc.edu> <20040506191351.GP23287@polop.usc.edu> <20040506215311.GA26968@polop.usc.edu> <20040506222455.GP18964@fieldses.org> <20040506230055.GC26968@polop.usc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: nfs@lists.sourceforge.net
In-Reply-To: <20040506230055.GC26968@polop.usc.edu>
Errors-To: nfs-admin@lists.sourceforge.net

On Thu, May 06, 2004 at 04:00:55PM -0700, Garrick Staples wrote:
> No effect.  All I did was kill mountd, run the patched mountd, and try to 'ls'
> on the client.

I think that's not enough....

> Watching an strace of mountd, it doesn't seem that mountd is ever contacted.
> The client reports stale filehandle pretty much immediately, and mountd doesn't
> do anything.

The upcall was made earlier, and the kernel has cached it (even if it's
a negative result).  So, just to make sure, could you try:

killall rpc.mountd
exportfs -f	#flush the kernel's caches
rpc.mountd	#(the patched version)

and then try again?

Of course, I may be barking up completely the wrong tree here, but I
think that bug in mountd could explain the problem you're seeing....--b.


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs