Re: Beyond inotify recursive watches

[Jan Kara <jack@suse.cz>]

On Fri 05-04-13 17:12:29, Al Viro wrote:
> On Fri, Apr 05, 2013 at 05:55:34PM +0200, Jan Kara wrote:
> 
> > What your question reminds me is an idea of recursive modification time
> > stamp on directories. That is a time stamp that gets updated whenever
> > anything in the tree under the directory changes. Now this would be too
> > expensive to maintain so there's also a trick implemented that you update
> > the time stamp (and continue updating recursive time stamps upwards) only
> > if a special flag is set on the directory. And you clear the flag at that
> > moment. So until someone checks the time stamp and resets the flag no
> > further updates of the recursive modification time happen.
> > 
> > This scheme works for arbitrary number of processes interested in recursive
> > time stamps (only updates of the time stamps get more frequent). What is
> > somewhat inconvenient is that this only tells you something in the
> > directory or its subtree changed so you still have to scan all the
> > directories on the path to modified file. So I'm not sure of how much use
> > this would be to you.
> 
> Feel free to write up the details of locking you'll need for that.  It will
> *not* be fun...
  Actually, it shouldn't be too bad if we don't guarantee we walk exactly
the path used for modification. Then it is enough to do the same thing as
following .. from each directory.

And for userspace that should be enough because if timestamp update races
with renames or similar actions somewhere up in the three then these
operations will generate modification events and update time stamps as
well. So userspace will notice there was a change.

So this part should be doable. But as I wrote before, we might need some
fs-internal index to allow efficient tracking of what has changed in one
directory anyway and locking rules / costs for that are non-obvious.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR