Bruce> We're intending a major rewrite of the code for Solaris.
Not quite, Bruce.
You may be intending a major rewrite of the code for Solaris.
*I'm* intending a major rewrite of the code overall.
(It's been a while since I completely broke a large portion
of the agent, and I'm getting withdrawal symptoms....)
Steven> [I now] call fstat to get the filesystem type every time.
Steven> Does this go against the original intent of the code?
Bruce> Personally don't intend on worrying too much about the original
Bruce> intent of the code. (Go ahead and yell at me)
YOU WHAT?!? <anything to oblige :-) >
As the original author, I am *very* keen that people working on this
functionality are clear about the original intent of the code.
The original intent of the code was as a "proof-of-concept"
implementation, that could be used for a while while experience
was gained with the problems inherent in monitoring this information.
The preliminary implementation could then be discarded, and new code
developed, learning from my initial mistakes.
Wes had to bully me into letting this code be released in the
first place, and I've been horrified at how much of it has survived
untouched for six or seven years.
It's about time that we stripped it down and started again!
Steven> I actually like part of the caching aspect because it helps you
Steven> detect when filesystems become unmounted.
I suspect some element of caching is going to be inevitable.
The model that I'm thinking of (and have hinted at to Bruce)
is a two-level cache, something as follows:
Every 1 hour (say), the agent searches to see what
disks/partitions/etc are available, and builds a
cached list of the current storage areas - this is
effectively "static" information.
Every 1 minute (say), the agent traverses this list
and updates the dynamic statistics for each entry
(size, used, I/O stats, etc).
Whether you regard the FSType as part of the static information
or dynamic is relatively unimportant. It could even be different
for different architectures (or even within a single architecture).
Those timescales are just for illustration, of course - there's nothing
hard and fast about them. And re-loading the caches could be done
regularly, or on-demand (or even a mixture of both).
And the other important element (stealing shamelessly from Robert's
I/F work), is that this cached data should be independent of any
given MIB implementation. So the same underlying cache could be
used for both the Host Resources MIBs, the UCD-SNMP-specific tables
and any subsequent re-workings of these (under the Net-SNMP banner).
There's absolutely no point in repeating the same data retrieval code
in two or more places. We need to have a single "access_data/filesys"
mechanism, that can be used by any MIB implementations that needs this
information.
That's the broad thrust of my current thinking, anyway.
I've no idea how it fits with what the two of your are doing.
Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
