From: Chuck Lever <chuck.lever@oracle.com>
To: Chris Carlson <c.carlson@aristoslogic.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: nfs_refresh_inode: inode number mismatch
Date: Tue, 11 Sep 2007 13:09:08 -0400 [thread overview]
Message-ID: <46E6CBB4.7020503@oracle.com> (raw)
In-Reply-To: <46E6C54F.4020100@aristoslogic.com>
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
Hi Chris-
Chris Carlson wrote:
> We are running MontaVista Embedded Linux 2.4 with NetApps NFS servers as
> the root filesystem and Linux 2.6 mounted filesystems. A simple test
> runs to copy files from one mount point to another (both are different
> directories on the same NFS server mounted at differet points).
>
> After 30 copies of a hundred files are made, the system is rebooted and
> the test repeats.
>
> After 2 reboots, an NFS file is created, and we get the following error
> from the kernel:
>
> nfs_refresh_inode: inode number mismatch
> expected (0x11/0xdacea3), got (0x11/0xb8d5e3)
>
> We're just trying to figure out what to do to figure out what the
> problem is. Is there a good place to place printks or breakpoints?
This may be due to an RPC XID collision. Which 2.4 kernel are you
using? The Linux NFS client may be sending the same XID sequence on the
same port number after each reboot, in which case the server will
respond with a cached reply rather than doing real work. The cached
reply may contain old file ID information, which triggers the "inode
number mismatch" message you see in your log.
One way to detect if this is happening is to use "pktt" on the filer.
You can capture a packet trace across client reboots to determine if
A) the transport socket's port number is the same across reboots, and
B) the RPC XID sequence is the same
[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard
[-- Attachment #3: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[-- Attachment #4: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-09-11 17:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 16:41 nfs_refresh_inode: inode number mismatch Chris Carlson
2007-09-11 17:02 ` Jeff Layton
2007-09-11 17:43 ` Jeff Layton
2007-09-11 21:11 ` Chris Carlson
2007-09-28 0:11 ` Chris Carlson
2007-09-28 14:52 ` Chuck Lever
2007-09-11 17:09 ` Chuck Lever [this message]
2007-09-11 21:15 ` Chris Carlson
2007-09-21 20:46 ` Trond Myklebust
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=46E6CBB4.7020503@oracle.com \
--to=chuck.lever@oracle.com \
--cc=c.carlson@aristoslogic.com \
--cc=nfs@lists.sourceforge.net \
/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