Messages in this thread | | | From | Hans-Peter Jansen <> | Subject | Re: [BUG] symlink problem with knfsd and reiserfs | Date | 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/
| |