Messages in this thread | | | Subject | Re: [patch] stop inotify from sending random DELETE_SELF event under load | From | John McCutchan <> | Date | Mon, 19 Sep 2005 23:46:55 -0400 |
| |
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/
| |