Re: patch for 2.0.31 NFS -- need testers!

Paul Slootman (paul@wau.mis.ah.nl)
Mon, 18 Aug 1997 12:29:48 GMT

Bill Hawes <whawes@star.net> wrote:
>Paul Slootman wrote:
>>
>> - 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
>
>Thanks for your comments ... the mode changing problem does need further
>work. The best solution is probably to define the inode_error_opertions
>structure to always return an error, but it also has to do the
>appropriate cleanup -- e.g. iput() inodes.
>
>On the other hand, in your example above, it looks like the inode should
>have been cleared after the rm file, so that the date > file command
>would get a fresh inode. Does the NFS server not indicate nlink = 0
>after deleting a file?

Yes, but it looks like the inode is being cached by the NFS client. If I
remove the symlink "file" (but wait with the "date > file" part), I can
see on the server itself that "file" is gone. If I now (on the client)
execute the "date > file" bit, the new "file" gets the same inode as the
old "file" had. The NFS client thinks it's the same file, and complains
about the mode being changed (it was a symlink, is now a regular file).
Some further experimenting shows that if I create a file in the same
directory on the server (e.g. with a different name) after removing the
symlink on the client, that newly created file gets the inode of the
symlink deleted on the client, which isn't a problem in itself. If I now
create "file" on the client, the nfs_refresh_inode message appears
again.

I think that if the client removes the file (and no silly rename stuff
needs to be done), it should flush any remembered info on that inode.

>> 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:
>
>> 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:
>
>Looks like what's happening is that rm -rf on the server doesn't care
>about any silly renamed files, and checking for such on the client side
>would make the operation painfully slow. So the removal of the file
>succeeds on the server despite the rename having taken place.

Just to be sure this is clear: I didn't do anything on the server
directly, the rm -rf was executed on the client. But, yes, the server
manages to remove the file :-)

>So there are two problems here: one is that some operations blow away
>silly renamed files, and the other is that the subsequent silly rename
>cleanup fails. Does error 116 mean "file not found"? If so, the second
>problem can be solved by checking for that code and not printing a
>complaint. (i.e. it's not a problem, since all we want to do is clean
>up.)

Error 116 is ESTALE "Stale NFS file handle", as far as I can tell.

>> Hope this helps...
>
>Yes, very much so. If the above resolution of the silly rename cleanup
>seems reasonable, I'll update the patch right away.

I'm not that good in NFS internals, so I have no idea what is the right
thing to do. BTW: I haven't noted any problems besides the syslog message.

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