[lkml]   [2005]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] stop inotify from sending random DELETE_SELF event under load

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_.


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,

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.076 / U:20.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site