On Fri, Sep 22, 2006 at 08:22:19AM +0200, Miklos Szeredi wrote: > > 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. 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. - 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
