Re: PATCH - Don't remove inode from hash until filesystem has deleted it.

[Neil Brown]

On Thursday May 8, [e-mail] 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