file system change notifications
Julian Elischer
julian at freebsd.org
Wed Mar 11 23:44:03 UTC 2015
On 3/11/15 3:46 PM, O'Connor, Daniel wrote:
>> On 12 Mar 2015, at 05:31, Kim Shrier <kim at westryn.net> wrote:
>> I have a project where I need to notice changes to files in a large directory tree.
>> I noticed that there was a project in GSOC 2010 to implement such a feature.
>>
>> https://wiki.freebsd.org/SOC2010IlyaPutsikau
>>
>> It appears that it was never completed. Is it desirable to have this project
>> completed and added into FreeBSD. Or, is there another way to get file
>> system change notifications?
> The 'standard' way is kqueue + masses of file descriptors.
>
> I am looking at using auditpipe(4) since you can register to be notified for all file modifications and you get a path.
>
> I wrote some test code at https://gist.github.com/DanielO/e36de242e79fed3fe4f7
>
> Ideally we could add an inotify() syscall although I think that is still suboptimal since you need to add a watch per directory so it can be relatively expensive to setup. That said working out what to do in the face of links and so on is tricky..
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
> -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
I think there are a few things that could lead to a relatively
efficient way of doing this..
if you wanted to watch all the files in a subtree, you should be able
to put an annotation in the vnode of base of that subtree, that would
indicate that fact. Then you could modify lookup/namei so that any
vnode returned from that lookup, that went past that notification
would also get the annotation. Obviously if the lookup was relative
then the anotation initial state would be inherrited from the start
point (CWD?). you woudl have to be ready to remove annotations on the
way down (..) but that seems doable. The annotations would refer to a
specific kevent item and child processes inherritance rules would work
as per normal.
each vnode coudl end up being watched by many kevents so therw woudl
have ot be some many to many mapping..
a cancelled kevent woudl need ot be able to remove all related
anotations, and a touched file woudl need to be able to make several
notifications.
The "hole" would be that vnodes that already exist within the watched
zone would not have the anotation, so you'd have to do root-wards
searches to add them when the zone was added (or just live with that).
If you search downwards towards root you have to add any annotation
you find on any ancestor vnode. but all file activities have to start
with an opened vnode somewhere.
More information about the freebsd-hackers
mailing list