Erich Schubert wrote: >Hi, > > >>I use inotify (needing kernel 2.6.13), the advantage is I will catch >>every file accessed in directories I monitor, the disadvantage is that >>it takes some time to setup monitoring those dirs (need one open on all >>directories, which causes some io wait). >> >> > >Have you considered using the audit interface? I used that to generate >my readahead-files, actually. I had some race issues, but after some >tweaking (and fixing of some related bugs in the kernel) it now worked >okay. > > No... but good idea, can you have multiple audit's monitoring at the same time?
>I'm not sure if I needed a modified auditd. I think I used the unmodified >one... >The real big issue with audit is that someone might want to use it for >something else... ;-) So I guess inotify is cleaner. But I'm not sure >about it performance-wise: what will it do when I e.g. list >/usr/share/doc ? or even when the updatedb cronjob kicks in? >Monitoring via /proc might skip these "fast" accesses. > > With inotify, you'll need to list which directories to monitor, but if that's setup to be everything in /lib /usr/bin /bin and so on, that catches pretty much everything you want to catch. And not skipping those "fast" accesses was a goal, I made one plugin scanning using /proc, and even when scanning many times a second and on many boots that never caught stuff like sed/bash and their respective libraries. And when doing readahead as early in the boot as possible, those are important. >btw, here is my auditd start script: >---.... >--- > >Basically this sets up a ramdisk and monitors all "open" and "execve" >calls. After all daemons have been started and some extra time has >passed I kill auditd and disable the notifications again. >Then some grep and filter magic to get the real readahead lists. > >Btw: someone suggested that readahead-list could use a \0-separated >list of filenames instead of a newline separated list. While the code >for the first case would indeed get easier (and eventually bring down >readahead-list below the 1k mark) and faster (no memcpy needed any >more), I think that doesn't outweigh the drawbacks in generating the >readahead file. comments? > > Use a memory mapped file when scanning, I find that practical when parsing simple files anyway. >best regards, >Erich Schubert >-- > erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_ > To understand recursion you first need to understand recursion. //\ > Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ > eine Stunde wie eine Heimat aus. --- Herrmann Hesse > >_______________________________________________ >initscripts-ng-devel mailing list >[email protected] >http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel > > > _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
