Messages in this thread | | | Date | Wed, 20 Aug 2003 11:43:04 -0700 | Subject | Re: NFS regression in 2.6 | From | Trond Myklebust <> |
| |
>>>>> " " == Andries Brouwer <aebr@win.tue.nl> writes:
> I don't think it will. My analysis of yesterday night was: > - no silly rename is done > - this is because d_count equals 1 > - this is because we have two different dentries for the same > file > - this is caused by the fragment
> /* If we're doing an exclusive create, optimize away > the lookup */ if (nfs_is_exclusive_create(dir, nd)) > return NULL;
> in nfs/dir.c. Do you agree?
No... The above snippet just short-circuits the process of doing an RPC call in order to look the file up on the *server*. Doing such a lookup would be wrong since it can race with a file creation on another NFS client. IOW the result of the above 2 lines should be the immediate creation of a negative dentry (i.e. one without an inode) that open_namei() can pass on to vfs_create().
When we get to the unlink() call, we shouldn't be hitting nfs_lookup() at all unless something somewhere is causing this first dentry to be permanently dropped out of the dcache.
In short the scenario should be that
- mkstemp() does an open(O_EXCL) -> nfs_lookup() creates hashed negative dentry -> nfs_create() then does an O_EXCL call to the server and instantiates the dentry.
- unlink() walks the pathname -> finds the existing dentry using cached_lookup() and only calls down to nfs_lookup_revalidate().
Cheers, Trond - 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/
| |