Date: Thu, 26 Jul 2001 21:09:50 +0200 From: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Alexander Leidinger <Alexander@leidinger.net>, freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org, <jlemon@freebsd.org> Subject: Re[2]: Monitoring a FS with kevent (was: Re: Redundant setup on a budget??) Message-ID: <34121816613.20010726210950@buz.ch> In-Reply-To: <20010726131609.K7716@prism.flugsvamp.com> References: <19297458367.20010726142352@buz.ch> <200107261742.f6QHgXv06426@Magelan.Leidinger.net> <20010726131609.K7716@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hello Jonathan, Thursday, July 26, 2001, 8:16:09 PM, you wrote: >> Jonathan, we are talking about soft-realtime mirroring of an >> entire FS (or doing something like realtime-tripwire). > That functionality would be nice to have (e.g.: for something like > cvsupd), but currently isn't handled by kqueue(). As described > above, EVFILT_VNODE monitors files (or directories) so you'd have > to > open each directory you wanted to monitor. Clearly a non starter... > This isn't ideal; suggestions on how things *should* work would be > appreciated. One of the main problems is that when the actual > event happens (at the vnode level), you only have the inode to > identify > things by, the pathname used is long gone. Well, I don't know (as I couldn't get it to build on 4.3 and 5.0 doesn't want to build...) whether this might help, but spy on http://people.freebsd.org/~abial takes an interesting approach: Generally, it seems to provide a facility to monitor arbitrary system calls, many of them including arguments. Now if someone monitors all open() call including arguments, it should be reasonably easy to write a log with changes to files for simple programs that open(), write(), close(). However, this obviously comes to the limits with daemons that normally keep their files open their whole "life" and might be writing times and times to them, so it probably would need to have some monitoring of the write() call too. How expensive is it to get the path of a file descriptor (not sure whether this can even be done with the current facilities, might need some array containing the descriptor numbers and the pathnames which could be maintained by messing around with open()/close())? As already said, I've been playing with the idea of letting libc do the logging as it knows the exact arguments to the open() calls (if mode != r, a modification is probable...) but here, the identical problem with daemons arises. A radically different approach would be to cache the entire directory structure in RAM which should allow dramatically faster polling at the cost of MB's of RAM but I think this isn't the optimal approach... Best regards, Gabriel -----BEGIN PGP SIGNATURE----- Version: PGP 6.5i iQEVAwUBO2Bc8sZa2WpymlDxAQHtaQgAzK4oYumnv0nL0xcGT6EZnvaO3Nsavgse krwSbLngw6wMYK7gKVqiXoAu7PmXMLoPfxU8dFbWREmDSn+27knNWYeoDt+Jh6Nd kjwh0iJR4fGkCaWPUWv4S/cU8Pn2xelMsqZxu1CTscF0Xe7ZjV1xtaGEyeAvAJPf XWM/c3uxf/dXoBjB9teF+7VWSYvZfUzcLezZAI6fVMi9XpfhVOJrW7r6hOus3xEG gjzzu4puUQQpB0C4/s7PL4SQkMh2aTheOcbJz2PHOuzPdJCEfetlaW1kGePTeZbr eqVUAVKMUMp+o/q2g+4twC/7MIBsRiDRrVAPjRMj4I4E6jXkDegPvg== =Vl9P -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-cluster" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34121816613.20010726210950>