Skip site navigation (1)Skip section navigation (2)
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>