Messages in this thread | ![/](/images/icornerl.gif) | | From | Neil Brown <> | Date | Fri, 9 May 2003 14:36:33 +1000 | Subject | Re: PATCH - Don't remove inode from hash until filesystem has deleted it. |
| |
On Thursday May 8, jaharkes@cs.cmu.edu wrote: > On Thu, May 08, 2003 at 11:44:32AM +1000, Neil Brown wrote: > > ------------------------------------------------------ > > Don't remove inode from hash until filesystem has deleted it. > > > > With this patch, the inode being deleted is left on the hash table, > > and if a lookup find an inode being freed in the hashtable, it waits > > in the inode waitqueue for the inode to be fully deleted. > > I could be wrong, but won't that break the following sequence of > operations, > > mkdir("foo", 0755); > fd = creat("foo/bar", 0644); > unlink("foo/bar"); > rmdir("foo"); /* this should succeed, but if the file is hashed > we get EBUSY here */ > close(fd); > > Or have potential deadlock effects when rmdir is replaced with some > operation that tries to perform a lookup for the inode, f.i. a > stat("foo/bar", &statbuf); > > Jan
Thankyou for your feedback.
However I don't think this is a problem.
The patch keeps the *inode* in the *inode hash table* slightly longer than normal, but it does nothing to any dentry that might be connected to the inode and might be hashed in a dentry table. So when you unlink("foo/bar") the dentry is treated just as it always is and is unhashed.
It is just the inode that instead of being unhash before the filesystem it told that it is to be delete (this is different from telling it that a filename is to be deleted), it is now unhash after the filesystem has completed it's deletion process.
NeilBrown - 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/
| ![\](/images/icornerr.gif) |