Alex Larsson wrote:
On Mon, 12 Nov 2001, Nathan Thompson-Amato wrote:
Isn't the signal-queue overflow something that needs to be handled anyway?
You're right, though, this patch doesn't even try to address either of
those problems.
It is supposed to be handled (but someone reported a bug about it), but
getting a signal overflow is very costly. You must conservatively assume
that all files in the system has changed, and scan them all.
Ouch. That *is* expensive...
For the application I'm working on, I want to keep statistics on how often
a certain (user-definable) group of files is read from and written to.
These statistics will be used for what amounts to a caching scheme for
files that are normally stored remotely.
Fam is not really accurate for this. Several accesses may be grouped
together into only one change. The only thing you should really rely on is
that the "final" state, after reading all events reflects the current
state.
This is okay for me -- I don't need tremendously precise stats, I just need
to know whether a file has been accessed "a lot" or "not much".
The only other ways I can think of to gather these statistics are periodic
polling (which is obviously bad for non-miniscule numbers of files) and
implementing a filesystem that tracks these things itself (ick)...
Or modify the apps that read these file to record statistics.
I don't think this is practical -- I need this to work transparently for
arbitrary (potentially binary-only) apps.
But now that I think about it, since I don't need a lot of precision, I
might just use the dnotify interface directly and not worry about some of
the edge cases (like signal-queue overflows).
Thanks very much for your feedback,
Nathan
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|