linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "Marco d'Itri" <md@Linux.IT>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: nfs_refresh_inode: inode number mismatch
Date: Thu, 19 Jul 2001 13:00:05 +0200	[thread overview]
Message-ID: <15190.48565.273451.582533@charged.uio.no> (raw)
In-Reply-To: <20010719002520.A5112@wonderland.linux.it>
In-Reply-To: <shsd76zsxd2.fsf@charged.uio.no> <20010719002520.A5112@wonderland.linux.it>

>>>>> " " == Marco d'Itri <md@Linux.IT> writes:

     > On Jul 17, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
    >> > Jul 18 00:15:07 newsserver kernel: nfs_refresh_inode: inode
    >> > number mismatch Jul 18 00:15:07 newsserver kernel: expected
    >> > (0x3b30ac75/0x48d5), got (0x3b30ac75/0x8d04)

    >> If, on the other hand, you're using a clean kernel, I'd look
    >> into what the server is doing. It sounds like it's doing the
    >> same thing that the userland `nfs-server' does: namely to
    >> recycle filehandles after a file gets deleted...
     > Anything specific I can tell to their tech support?

     > Can I ignore these messages or I risk data corruption?

There's always a small danger of data corruption, since the NFS client
can't rely on the file handle actually being a pointer to the file we
expect.

Try 2.4.6 first though, as a couple of fixes were implemented there
that should reduce the frequency of such messages. Basically we ensure
that inodes are removed from the cache when we do believe that it has
been deleted.

A proper fix, though, would be for the server to implement filehandles
that are unique as per RFC1813...

Cheers,
  Trond

  parent reply	other threads:[~2001-07-19 11:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-17  0:24 nfs_refresh_inode: inode number mismatch Marco d'Itri
2001-07-17  9:44 ` Trond Myklebust
2001-07-18 22:25   ` Marco d'Itri
2001-07-19 11:00   ` Trond Myklebust [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-06-03 23:54 Frank Cusack
2003-06-04 14:19 ` Trond Myklebust
2003-06-04 21:20   ` Frank Cusack
2003-06-04 21:28     ` Trond Myklebust
2003-06-05  9:11     ` Adrian Cox
2003-06-05  9:13       ` Russell King
2003-06-05 13:51         ` Trond Myklebust
2001-02-22 22:30 Scott A McConnell
2001-02-22 21:59 ` Russell King
2001-02-23  9:30   ` Trond Myklebust
2001-02-08  1:13 Jun Sun
2001-02-08  1:22 ` Neil Brown
2001-02-08  8:08   ` Russell King
2001-02-09  0:02     ` Jun Sun

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=15190.48565.273451.582533@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@Linux.IT \
    /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;
as well as URLs for NNTP newsgroup(s).