![]() | |||||||||||||
Messages in this thread |
On Wed, Jun 11, 2003 at 03:27:54AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote: > On Wed, Jun 11, 2003 at 03:59:10AM +0200, Trond Myklebust wrote: > > IOW we just want to prevent VFS from unhashing the dentry in the first > > place: dentry aliasing cannot work together with sillyrename. > > Aliasing could be dealt with. They would have the same inode, so it's > easy to detect. dentry only contains the inode, not the fh. On the server, the inode can go away and come back as a new fh, but with the same inode. Is that detectable (would comparison hooks have to be added?)? Although, I guess the inode is enough; you can do an NFS_I(inode)->fh to get the fh, but I wouldn't guess you'd want that in the VFS. Bah, here I go again ... forgive me if that's nonsense. > The real problem is different: what happens if I take > silly-renamed file and rename it away? You suddenly get ->dir and ->dentry > if your nfs_unlinkdata having nothing to do with each other. You could disallow rename if DCACHE_NFSFS_RENAMED is set. That would be easy and makes sense as an "ok" thing to do. I mean, if you're not going to allow unlinking of a sillyrenamed file, you may as well disallow rename as well. If that's not desirable (again, seems ok to me ... speaking as just a user) then hey, in rename you just need to check the nfs_delete_queue. > _If_ we want to be able to work with silly-renamed dentry, we need much > more careful async unlink. Your current code assumes that these dentries > won't go anywhere. AFAICS, dcache will not get into inconsistent state, > but it will have very little to do with state of server... OK, where else besides rename would the dentry change? /fc - 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/ | ||||||||||||
| Last update: 2005-03-22 12:36 [W:15.006 / U:0.060 seconds] ©2003-2008 Jasper Spaans | |||||||||||||