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)
I've got a flood of these messages while talking to a procom NAS this.
Should I worry? Upgrade/patch the kernel? Yell at procom tech support?
Linux newsserver 2.4.5 #1 Fri Jun 22 18:18:56 CEST 2001 i686 unknown
192.168.139.11:/news_store on /shared/archive type nfs (rw,noatime,rsize=8192,wsize=8192,udp,nfsvers=3,addr=192.168.139.11)
--
ciao,
Marco
>>>>> " " == Marco d'Itri <[email protected]> writes:
> 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)
> I've got a flood of these messages while talking to a procom
> NAS this. Should I worry? Upgrade/patch the kernel? Yell at
> procom tech support?
Have you applied any extra patches to NFS? I remember one of my
patches (availalble from my WWW-page, but clearly marked experimental)
was generating these messages gratuitously.
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...
Cheers,
Trond
On Jul 17, Trond Myklebust <[email protected]> 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)
> > I've got a flood of these messages while talking to a procom
> > NAS this. Should I worry? Upgrade/patch the kernel? Yell at
> > procom tech support?
>Have you applied any extra patches to NFS? I remember one of my
No, the kernel is plain unpatched 2.4.5.
>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?
--
ciao,
Marco
>>>>> " " == Marco d'Itri <[email protected]> writes:
> On Jul 17, Trond Myklebust <[email protected]> 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