linux-mips
[Top] [All Lists]

"exportfs -a" -> stale NFS filehandle

To: <linux-mips@linux-mips.org>
Subject: "exportfs -a" -> stale NFS filehandle
From: "Kaz Kylheku" <kaz@zeugmasystems.com>
Date: Wed, 14 Nov 2007 15:19:43 -0800
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcgnFNbW97dDhBWkQhSAn9o02emXvQ==
Thread-topic: "exportfs -a" -> stale NFS filehandle
Hi all,

I have an NFS problem on a multi-node MIPS system running kernel
2.6.17.7. NFS utils is 1.1.0. ABI is n32.

One node (call it primary) exports a directory which is mounted by
several others (the secondaries) as their root filesystem.

If I run "exportfs -a" on the primary, the secondary nodes lose their
root filesystem and so everything stops working.

I turned on all NFS debugging on a secondary node (sysctl -w
sunrpc.nfs_debug=65535). What is happening is that NFS operations
suddenly start returning error -151 (stale NFS filehandle).

I don't see exportfs causing this problem on other systems. If I run
"exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots
of diskless clients, nothing bad happens. (And some of those diskless
clients are MIPS systems just like this one!)

I'm pretty sure that exportfs -a shouldn't screw up the existing mounted
clients.

Could there be some ABI problem that corrupts up the effect of the
re-exporting operation on the server?

(This issure reproduces always. Something which reproduces rarely is a
kernel crash on a secondary node, inside the nfsd process, also
apparently in response to the "exportfs -a". I don't yet have enough
information about that one, such as a call trace, etc. That one I can
drill into, if I have a program counter and call stack.)







<Prev in Thread] Current Thread [Next in Thread>