> I have just compiled and installed imon-0.0.1-2.2.13, fam-oss-2.6.3 on
> version 2.2.15 of the Linux kernel. The compilations all worked fine
> with no errors. When I boot with the new kernel, I get a message saying
> 'imon (inode monitor) $Revision: $' which all looks fine but once the
> system is up and running, /dev/imon doesn't seem to exist. It does on my
> IRIX 5.3 system so I guess it should be visible. Do I need to do
> something to create it or has something gone wrong?
No, it's OK; on Linux, when fam starts up, it creates /dev/imon with the
major number it reads from /proc/devices. (Then it promptly deletes the
device; the person who wrote that part felt there was no need for
/dev/imon to hang around.) That bothers enough people that I will add it
to the FAQ, and possibly remove the bit in fam which removes /dev/imon.
If you want to make sure fam is using imon instead of polling, there are a
couple of things you could do: one is to add the -d flag (for debugging) to
the line in /etc/inetd.conf which starts fam, and killall -HUP inetd, and
make sure your syslog configuration will dump debug messages somewhere where
you can find them. When fam starts up, it should say whether it was able to
open /dev/imon. (It should probably do that even when it's not in debug
mode, since that's a pretty interesting piece of information!)
Another thing you can do (easier, actually) is cat /proc/fs/imon-meter or
/proc/fs/imon-hash (unless you turned off DEBUG_INTO_PROC in your
linux/fs/imon/imon.c). If imon is monitoring any files, the "base" line in
/proc/fs/imon-hash will have an address other than 0, and there will be a
list of hash table entries. If imon *has* monitored any files (even if none
are being monitored now), the "adds" line in /proc/fs/imon-meter will be
non-zero.
> Would it make sense to use fam in programs which are just interested in
> monitoring single files such as a text editor monitoring the file it has
> open or are the overheads such that it is only worth using if a whole
> directory structure is going to be monitored?
We're talking about NEdit, right? (I love nedit!) I don't know. NEdit
stats the file you're editing when the window gets focus, right? That seems
pretty simple, and because it's based on user action rather than polling
periodically, it means it really isn't doing anything when it's minimized or
stowed or whatever. On the other hand, you *are* polling when you don't need
to, and on the other other hand it seems like you could get into cases where
the user has been typing into the same window for five minutes without
knowing that the file changed underneath them four minutes ago. Whether that
justifies the overhead of fam (and how much overhead there really is) I don't
know. Once you're running, I think there's basically no overhead (just one
more fd in the select), but when you connect to fam, FAMOpen() has to get a
port number from the portmapper, and open a couple of sockets, so there's a
bit of overhead there. If fam isn't already running, then someone has to pay
for inetd forking & starting it up, but only the first client has to do that.
--Rusty
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|