Re: [patch] stop inotify from sending random DELETE_SELF event under load

[John McCutchan <ttb@tentacle.dhs.org>]

On Mon, 2005-09-19 at 19:20 -0700, Linus Torvalds wrote:
> 
> On Mon, 19 Sep 2005, John McCutchan wrote:
> > 
> > To quote you:
> 
> Yeah, sometimes I'm more right than other times. That wasn't one of them.
> 
> It's actually _almost_ right. The problem being that dentry_iput() is 
> called for non-delete events too.
> 
> However, your patch is _worse_. Your patch will cause it not to report the 
> delete at all, because what will happen is that if the delete() is done 
> while somebody else has a pointer to the dentry, then we won't call 
> "dentry_iput()" with a "delete" AT ALL. We will only call it later when 
> the _other_ person (who didn't do a delete) releases the dentry.
> 
> See? It's very very wrong to send a flag that depends on the call-chain, 
> because the call-chain is _not_ what determines whether the inode gets 
> deleted or not.
> 

Yeah, I see this now. 

> The only way to know whether it gets deleted or not is whan the actual
> i_nlink goes down to 0, and the inode gets deleted. Ie exactly the
> generic_delete_inode() case.
> 
> But if you keep a reference to the inode, that will never actually happen. 
> Hmm.
> 
> Who wants that inode delete event anyway? It's fundamentally harder than 
> removing a name, partly because of the delayed delete, partly because an 
> inode may be reachable multiple ways.
> 

I think the name fsnotify_inoderemove is causing some confusion. We only
care that some name that is pointing to this inode has been deleted. 
Remember, it was suggested as a replacement for fsnotify_unlink. We
don't care if the inode is actually going away or not. 

> Maybe this patch instead? It's not going to be reliable on networked 
> filesystems, though. Nothing is.
> 

Thanks, I will have it tested.

-- 
John McCutchan <ttb@tentacle.dhs.org>
-
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/