>+ /*
>+ * Check whether the i_op pointer changed ... we don't want
>+ * pre-tested i_op entries to become invalid or NULL.
>+ */
>+ if (old_ops && inode->i_op != old_ops) {
>+ printk("nfs_refresh_inode: mode changed i_op, old=%x new=%x\n",
>+ old_mode, inode->i_mode);
>+ /* For now, just complain */
>+ /* inode->i_op = &inode_error_operations; */
>+ }
OK, I can trigger this:
- On the NFS server, have a file symlinked to a subdirectory like so:
mkdir testdir testdir/subdir
cd testdir
date > file
ln -s file subdir
- Now on the client, do this:
cd testdir/subdir
rm file; date > file
This will do it every time. The message reported is
nfs_refresh_inode: mode changed i_op, old=a1ff new=81a4
server: Solaris x86 2.5.1 server OR Linux 2.0.18 with "Universal NFS
Server 2.2beta16" (Red Hat 4.0).
client: Linux 2.0.30 + pre-patch-2.0.31-5.gz + this NFS patch.
Another point:
I (still) get
NFS silly_rename cleanup failed (err = 116)
when running test 12 from Vim 5.0 on an NFS fs (mounted from the same
servers as above). I've managed to minimize this to the following:
- Open a file in a subdirectory
- execute "rm -rf" on the subdirectory
- close the file
- (try to) remove the file
A perl script that does this is:
mkdir("testdir", 0775);
open(TEST, ">testdir/file");
system("rm -rf testdir");
close(TEST);
unlink("testdir/file");
exit(0);
Replacing the "rm -rf" with unlink(file); rmdir(directory) won't work,
as the rmdir fails (because of the .nfsXXX file created). rm -rf
somehow manages to get rid of the .nfsXXX file, and then rmdir the
directory. Strace-ing rm -rf shows that:
- stat("testdir") is followed by open("testdir") followed by
getdents() and close()
- getdents() returned 3 entries
- it unlinks "testdir/file"
- it again does stat("testdir") is followed by open("testdir") followed
by getdents() and close()
- getdents again returned 3 entries
- it unlinks "testdir/.nfs478142"
- it again does stat("testdir") is followed by open("testdir") followed
by getdents() and close()
- getdents now returned 2 entries
- rmdir("testdir")
Hope this helps... If you need any more info, please cc: paul@murphy.nl
as I usually gate linux-kernel into a newsgroup (private, local, one-way
only, don't panic!) and replies might expire before I get the chance to
read them.
Paul Slootman
--
Murphy Software, Enschede, The Netherlands | Most people would die
email work: paul@wau.mis.ah.nl / paul@murphy.nl | sooner than think --
email home: paul@wurtel.demon.nl | in fact, they do so.
http://www.wurtel.demon.nl | - Bertrand Russell