Monitoring FS changes

[Konstantin Belousov]

On Mon, Jan 04, 2016 at 11:59:32AM -0800, Sean Eric Fagan wrote:
> >The generic problem we have there is quite different. Assume that
> >we establish a new monitor on a directory, and assume there exists
> >previously open file, which vnode should be now monitored by the
> >'children' rule. How can we learn that the vnode must be included in the
> >watching set, i.e. marked ? Same issue occurs for fhopen() and for NFS
> >handles.
> 
> xnu solved that by putting a parent pointer in each vnode (obviously, not set
> for non-fs objects).  Once they did that, this kept a reference for each
> vnode, and voila, always there.
The voila part is somewhat problematic.

You must ensure the liveness of the reference to the parent vnode, which
immediately raises the question of parent vnode being recycled without
updating the children pointers.  So you must track all children, to not
leave stale parent pointers around.  This is because vnodes only represent
a cache of the on-disk structures.

We do have a machinery to track the parent/children relations, it is called
the name cache.  But it is a cache and can be dropped at any time.  This
is why e.g. vn_fullpath() or executable names in /proc or lsof output
are lost sometime.

Anyway, having great ideas does not make this stuff implemented even a
bit closer. If anybody with his/her great ideas does not bother even to
formulate the wanted API and explicitely document desired behaviour, the
thing will never happen.

> 
> They also keep a reference cache of names; this makes a lot more sense on a
> Mac OS system since so many directories and files have the same name
> (there are 9400 instances of "Info.plist" on my laptop at the moment, for
> example).
> 
> The memory footprint for each of these was not too large.  But, then, Apple
> wasn't supporting systems with less than 1gbytes of ram at the time 8-).