Messages in this thread | | | From | Nikita Danilov <> | Date | Fri, 23 Apr 2004 20:20:50 +0400 | Subject | Re: d_splice_alias() problem. |
| |
Andreas Dilger writes: > On Apr 23, 2004 17:02 +0400, Nikita Danilov wrote: > > Suppose we have an inode with ->i_nlink == 1. It's accessed over NFS and > > DCACHE_DISCONNECTED dentry D1 is created for it. Then, unlink request > > comes for this file. nfsd looks name up in the parent directory > > (nfsd_unlink()->lookup_one_len()). File system back-end uses > > d_splice_alias(), but it only works for directories and we end up with > > second (this time connected) dentry D2. > > > > It's hard to imagine how new name can be identified with one among > > multiple anonymous dentries, which is necessary for > > NFSEXP_NOSUBTREECHECK export to work reliably. > > > > One possible work-around is to forcibly destroy all remaining > > DCACHE_DISCONNECTED dentries when ->i_nlink drops to zero, but I am not > > sure that this is possible and solves all problems of having more > > dentries than there are nlinks. > > We use a patch for Lustre which solves this problem. When there is > a lookup-by-inum done on the server there is the possibility to get a > DISCONNECTED dentry as you say. However, if we ever do another lookup > on this inode we verify that either this is a disconnected dentry and > return the existing dentry, or if it is a connected dentry we essentially > "rename" the disconnected dentry and connect it to the tree and return > that. There can never be both connected and disconnected dentry aliases > on an inode at one time.
I am not sure I understand this description correctly, but it looks pretty much like what d_splice_alias() is supposed to do according to the comment on top of it.
What I missed is that inode can have no more than one disconnected dentry even if it has multiple names. Hence when lookup-by-name happens list we can d_move disconnected dentry in place of the named one. This is no worse that what is done currently by d_find_alias() that identifies disconnected dentry with arbitrary connected.
> > This is handled inside the ext3 lookup code, I'm not sure how easy/hard > it would be to make a generic VFS patch to do the same. > > Cheers, Andreas
Nikita. - 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/
| |