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

[Al Viro <viro@ftp.linux.org.uk>]

On Tue, Sep 20, 2005 at 11:12:02AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 20 Sep 2005, Ray Lee wrote:
> > 
> > I can't even talk to that level, but perhaps it'd help to know that some
> > (I think) are pinning their hopes on inotify as the foundation of a
> > userspace negative dentry cache (i.e., samba trying to prove a set of
> > filenames (case-insensitively) doesn't exist).
> 
> Note that than you should use the _name_ caching part, ie the 
> fsnotify_nameremove() part of the equation. That part is unambiguous.
> 
> It's literally only the "inode" things (IN_DELETE_SELF) that are
> questionable. And that's fundamentally because the "self" can live on for
> _longer_ than the name that points to it.
> 
> I really think that the patch I sent out yesterday is as good as it gets.  
> If you want immediate notification, you should ask for notification about
> name changes in a particular directory. IN_DELETE_SELF notification on a
> file simple is _not_ going to be immediate.

But then it's too early.  Note that with your patch we still get removal
of _any_ link to our inode (even though it's alive and well and we'd never
heard about the sodding link in the first place) terminating all events
on it.  See example upthread - we have two links to the same inode;
the_only_name_we_know and ~luser/foo/bar/baz.   We watch the_only_name_we_know.
Luser goes spring-cleaning and does rm ~luser/foo/bar/baz.  Now we suddenly
get IN_DELETE_SELF on our watch *and* stop getting anything coming on that
sucker.

This is obviously broken - even if we reinstate the watch (after figuring out
that there had been no events on parent), we are already too late - we've
lost an unknown number of events _and_ had to do non-trivial cleanup in
the client (including redoing stat() and friends if we are going to compensate
for the lost events).