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

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

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>