Date: Thu, 17 Nov 2005 11:23:57 -0600 From: Eric Anderson <anderson@centtech.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem monitoring question Message-ID: <437CBCAD.3080600@centtech.com> In-Reply-To: <20051117171414.L77687@fledge.watson.org> References: <a9f55af40511170707n3dd70429t48d85acf9b3be5f4@mail.gmail.com> <437CB004.2000401@tirloni.org> <20051117171414.L77687@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Thu, 17 Nov 2005, Giovanni P. Tirloni wrote: > >> Using kqueue you can monitor a file/directory for changes and have it >> trigger something when that event happens. But you want to monitor you >> whole partition.. perhaps intercept some syscalls ? > > > Depending on your requirements, you may be able to use ktrace(1) to > monitor the path lookups of all processes on the system by logging them > to a file and tracking the file. > > With Audit support, shortly to be imported into the tree, you'll be able > to do similar things, although in a more configurable way. This got me thinking - what would be the appropriate way for someone to have the kernel dump filesystem info to a userland process? What I'm wondering, is if one could wedge in some parts to the vfs code, that spits out things like vnode, vnop, etc, to a place where a userland app could listen and do something with that info. It would have to be a path that would cause the least delay in dumping the data of course, perhaps a /dev/ device entry, or unix domain socket? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?437CBCAD.3080600>