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

From: John McCutchan
Date: Tue Sep 20 2005 - 19:52:53 EST


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@xxxxxxxxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/