On Mon, 12 Nov 2001, Nathan Thompson-Amato wrote:
> Alex Larsson wrote:
>
> >
> > Hmm. This has the potential to easily flood and overflow the signal
> > queue. It can also very easily chew up a lot of CPU, since all
> > accesses in the filesystem cause fam to rescan it's directories.
> >
>
>
> 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.
> > What is the reason you want this?
>
>
> 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.
> 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.
/ Alex
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|