lkml.org 
[lkml]   [1997]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: patch for 2.0.31 NFS -- need testers!
Paul Slootman wrote:
> 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

Paul,
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?

> 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.

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.)

> 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.

Regards,
Bill

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:1.108 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site