Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Mar 2015 16:43:41 -0700
From:      Julian Elischer <julian@freebsd.org>
To:        "O'Connor, Daniel" <darius@dons.net.au>, Kim Shrier <kim@westryn.net>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: file system change notifications
Message-ID:  <5500D32D.30703@freebsd.org>
In-Reply-To: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au>
References:  <C4BD68D4-0570-4731-AFA2-CDD4DD5490E5@westryn.net> <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On 3/11/15 3:46 PM, O'Connor, Daniel wrote:
>> On 12 Mar 2015, at 05:31, Kim Shrier <kim@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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@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.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5500D32D.30703>