Re: [BUG] symlink problem with knfsd and reiserfs

Hans-Peter Jansen (hpj@urpla.net)
Tue, 15 Jan 2002 16:32:12 +0100


On Tuesday, 15. January 2002 15:07, Nikita Danilov wrote:
> Trond Myklebust writes:
> > >>>>> " " == Hans-Peter Jansen <hpj@urpla.net> writes:
> > > In syslog, this message appears: Jan 15 00:21:03 elfe kernel:
> > > nfs_refresh_inode: inode 50066 mode changed, 0100664 to 0120777
> >
> > The error is basically telling you that ReiserFS filehandles are being
> > reused by the server. Doesn't Reiser provide a generation count to
> > guard against this sort of thing?
>
> Yes, inode->i_generation is stored in the file handle:
> fs/reiserfs/inode.c:reiserfs_dentry_to_fh().
>
> Hans-Peter, what version of NFS are you using and have you remounted
> clients after upgrading to the newer kernel?

I can reproduce it with 2.4.5, 6, 13-ac7, 18-pre3 with and without Trond's
NFS-ALL patches applied. I don't understand your question, but testing this
implied several reboots of the server and some dozen reboots on the client.

The lm_sensors build reproduced it pretty stable (with a few exceptions,
and on different commands of the range ar, gcc and ln)
Test is pretty simple: clean make of lm_sensors almost all the time
triggers it. If not, just rm lib/libsensors* and make again. This
created certainly stale files lib/libsensors.so|lib/libsensors.so.1
from within the client. You can only get rid of them by rebooting or
removing them on the server.

> > My 'fix' just solves the immediate problem of the wrong file mode. It
> > does not solve the problems of data corruption that can occur when the
> > client is incapable of distinguishing the 'old' and 'new' files that
> > share the same filehandle.
>
> This requires i_generation overflow (modulo bug in reiserfs).

Please, try to reproduce it, and let us know, if you can reproduce it.

> > Cheers,
> > Trond
>
> Nikita.

Cheers,
Hans-Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/