On Tue, 29 Mar 2011 10:17:26 -0500 David Young <[email protected]> wrote:
> Are you sure that kqueue supports monitoring trees? I know that > it's possible for to watch a directory with kqueue for nodes > added/deleted/renamed, however, when a process watches directory x/ with > kqueue it won't necessarily wake up if there is a change under x/y/ or > x/y/z/. I remember participating to an older thread on this subject here years ago, and indeed kqueue lacks the ability to monitor trees. If I remember, one of the conversations did evolve around the possibility for kqueue to eventually be able to report events for a whole filesystem, although if this was done the security model has to be thought of carefully. An event could for instance hold the following fields: inode, event, nparams, params[] or the like. I'm not sure if this is a requirement for inotify, but another potential issue is the reverse mapping of inodes to paths; also long ago I implemented a userland daemon to do this and realized that for large trees the memory requirements were rather large (I didn't bother implementing compression for it though). Of course this gets complicated by the fact that multiple paths may lead to a common node, but it wouldn't be very hard for the kernel to remember one of the paths to every active vnode, possibly... which would also benefit fstat(1) and procfs... -- Matt
