> > > I'm thinking something along the lines of the following patch on top of > > > David's d_materialise_dentry(), which is already in the 2.6.18-mm > > > kernels. Still untested (I'm working on that), but it attempts to do > > > what you were proposing: > > > > > > 1) If instantiating a directory, check for aliases > > > 2) If an alias is found in the dcache, attempt to rename the > > > existing dentry instead of instantiating the alias. > > > 3) Return ELOOP if the alias turns out to be a parent. > > > > What I'm still worried about is that by moving the alias across > > directories without holding the rename mutex, you are violating a > > premise in the cross directory rename locking rules: > > > > (2) if cross-directory rename holds the lock on filesystem, order will not > > change until rename acquires all locks. (Proof: other cross-directory > > renames will be blocked on filesystem lock and we don't start changing > > the order until we had acquired all locks). > > > > Possible solution: > > > > - if lookup is being called for last components in rename then > > s_vfs_rename_mutex is already held, we are OK. But currently we > > don't know if lookup is called from rename. > > > > - otherwise trylock on s_vfs_rename_mutex, if succeeds then OK. > > > > - if fails, then alias can't be moved, make the inode bad (which > > also unhashes it) and get a new inode, which will now be > > unaliased. > > > > Also need to trylock i_mutex on alias->d_parent->i_inode after having > > acquired s_vfs_rename_mutex for similar reasons. > > > > However it's getting rather ugly, and I'd rather have something > > simpler. > > Simpler: if alias and our dentry share the parent, it's locked and > we can rename without s_vfs_rename_mutex. If they do not, walk the > tree under alias, unhash all non-directories and kill all directories. What do you mean by "killing directories"? Unhashing the inode? Are these OK, without holding i_mutex on alias and descendents? > We keep local renames, we keep renames within directory and cross-directory > rename on server ends up with invalidation when client notices it. > > We don't _care_ if lookup() is not from rename. That's OK. Well, there's the strange case of shared parents and lookup moving the source into the target, effectively completing the rename, and thus making rename think the source and target were equal, although in fact they weren't... Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
