>>
>>
>> > Take two machines. Call them (1) and (2) in this case. Make
>> > them both Linux machines. Do the following, in this order:
>>
>> > 1: mkdir bla 1: touch bla/foo.x 2: touch bla/foo.y 1: rm -rf
>> > bla 1: mkdir bla 2: ls -ls bla
>>
>> > The result of the "ls -ls" will produce nothing on FreeBSD or
>> > Solaris, but on Linux, it's "Stale file handles" up the
>> > wazoo. I think I know how to fix this as well, but I'm still
>> > poking about, but I believe that just fixing up
>> > nfs_invalidate_inode to do the appropriate thing when it's a
>> > directory and offset of 0 will do the trick. :)
>>
>> > Thoughts?
>>
>> Hi Steve,
>>
>> The following patch to stock linux-2.2.10 fixes the problem for
>> me. Please try it out... If it works out OK, perhaps Alan could
>> apply it to the 'ac' series too?
>>
>> Sorry I didn't reply earlier, but I'm off on holiday this
>> week. I just quickly popped in to the office to read my mails
>> today...
>>
>>
> Have you looked at the patch from me and Steve?
Are you talking about the patch to fs/nfs/inode.c that was posted to
nfs-devel? Please don't take offence, but that patch seems completely
wrong to me.
The nfs_proc_lookup in function _nfs_revalidate_inode is only there
for debugging purposes (it looks up any existing new file handle in
order to provide a nice resume in the kernel error log of the ESTALE
error). The fact that it returns NFS_OK doesn't mean a thing since we
don't use the looked up information to update the stale file handle
(and we don't want to since that could mean that asynchronous writes
end up overwriting the new file instead of failing).
The correct place IMHO for solving this problem is in the revalidation
of the cached dentries themselves (not the inode!), which means
nfs_lookup_revalidate and/or nfs_lookup. This ensures that the problem
is solved upon reopen of the file/directory which is what users would
normally expect.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/