Messages in this thread | | | Subject | Re: [patch] stop inotify from sending random DELETE_SELF event under load | From | John McCutchan <> | Date | Tue, 20 Sep 2005 20:52:59 -0400 |
| |
On Tue, 2005-09-20 at 17:33 -0700, Linus Torvalds wrote: > > On Tue, 20 Sep 2005, John McCutchan wrote: > > > > Is there some reason we can't just do this from vfs_unlink > > > > inode = dentry->inode; > > iget (inode); > > d_delete (dentry); > > fsnotify_inoderemove (inode); > > iput (inode); > > Mainly that it slows things down, and that it's wrong. > > The thing is, I don't consider fsnotify_inoderemove() that important. > > It is a fundamentally broken interface. We should document it as such. It > is _senseless_. > > If you want immediate notification of a filename going away, then check > the directory. That is something with a _meaning_. > > But the whole IN_DELETE_SELF is a STUPID INTERFACE. > > I don't want to have stupid interfaces doing stupid things. > > I'm perfectly willing to give an approximate answer if one is easy to > give. But there IS no "exact" answer, as shown by the fact that you didn't > even know what the semantics should be in the presense of links and > keeping a file open. > > The file still _exists_ when it's open. You can read it, write it, extend > it, truncate it.. It's only the name that is gone. So I think delaying > the "IN_DELETE_SELF" until you can't do that any more is the RIGHT THING, > dammit. > > All of the problems with the interface have come from expecting semantics > that simply aren't _valid_. > > Live with the fact that files live on after the name is gone. Embrace it. > IT'S HOW THE UNIX WORLD WORKS. Arguing against it is like arguing against > gravity. >
Alright, at this point I was just throwing out ideas ;). Anyways, you've convinced me! Now, what about my last patch and your last patch getting included?
-- 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/
| |