From: Jeff Layton Subject: Re: nfs_refresh_inode: inode number mismatch Date: Tue, 11 Sep 2007 13:43:53 -0400 Message-ID: <20070911134353.60e7bda7.jlayton@redhat.com> References: <46E6C54F.4020100@aristoslogic.com> <20070911130226.131bad3d.jlayton@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: "Chris Carlson" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1IV9nG-0005tv-16 for nfs@lists.sourceforge.net; Tue, 11 Sep 2007 10:44:58 -0700 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IV9nK-00062B-Ak for nfs@lists.sourceforge.net; Tue, 11 Sep 2007 10:45:02 -0700 In-Reply-To: <20070911130226.131bad3d.jlayton@redhat.com> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net On Tue, 11 Sep 2007 13:02:26 -0400 Jeff Layton wrote: > On Tue, 11 Sep 2007 09:41:51 -0700 > "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) > > > > This may be a bug in the NetApp. I saw some similar messages when > working on an issue and it turned out to be a filer bug. I ended > up tracking it down by doing network captures, and then searching them > for the 'expected' and 'got' sequence of bytes in wireshark. It showed > that in some cases the netapp was sending back a new fileid in the > WCC attributes for the dir when a create call would fail. > For the record, the NetApp engineers I worked with on this issue referenced NetApp BURT: 244015: We should not have pre/post attributes in case of an error coming from exports code You might want to check that your filer has that fix. -- Jeff Layton ------------------------------------------------------------------------- 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/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs