Monitoring FS changes

[Konstantin Belousov]

On Mon, Jan 04, 2016 at 11:03:30PM +0800, Julian Elischer wrote:
> I think the point is that setting  a notify onto a directory vnode 
> would force all directory vnodes above it (away from root)
> to stay in memory. That gives a path to traverse in memory to look for 
> notify hooks when a change is made..
No, it is not. On lookup, you can mark instantiated vnodes, which are
children of the monitored vnode, specially. This does not change the
existing lifecycle of the vnodes, does not require to make all childs
unreclamaible, and allows the caching to work. The tracking might be
done with either modest struct vnode grow or even without, by placing
several strategic hooks into the vnode lifecycle code.

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.

AFAIU, Linux solves it by making the name cache reliable, so you always
know if the used name for the vnode is the child of the monitor root.
This also explains why they cannot detect hard links.

> This has been discussed many times before.  many yearsa ago it came 
> down to resources usage.. I'm not sure that is so important with 128GB 
> machines.
> (but it needs to handle runaway resource usage). The exact syntax of 
> what is required needs to be spelled out well (as kib says).
> 

As explained above, this is not the issue.

Whether the problem I noted is important for the requested API, can be
only understood after the API requirements are provided.  Even if it
is important, might be some significant group of consumers still do not
care or can accept such problem.