This is a discussion on Re: net-snmp 5.4 and very large filesystems - SNMP ; On 05/07/07, Bruce Shaw wrote: > I'm worried about the folks using MRTG who are expecting consistent > values. They're gonna have problems if the size keeps jumping around > 'cause we're fiddling with hrStorageAllocationUnits. That's partly why I'd prefer ...
On 05/07/07, Bruce Shaw
> I'm worried about the folks using MRTG who are expecting consistent
> values. They're gonna have problems if the size keeps jumping around
> 'cause we're fiddling with hrStorageAllocationUnits.
That's partly why I'd prefer to concentrate on addressing this
as part of a complete reworking of the HR Storage Table.
Significant re-writes can legitimately introduce behaviour
changes, that would be unnacceptable in minor releases.
As far as the immediate problem is concerned, the simplest
approach might be either:
a) To latch reported values at the range maximum
(INcorrect, but less confusing than wrapping into negative values)
b) Provide a configure directive to specify the units
(rather than hardcoding 512 bytes)
> Proposed solution:
> 1. nasty hack to allow LARGEFILE support not to trigger the compiler
> when it sees sysctl in use. (this actually solves several problems)
> 2. If we see an EFI-compliant disk label, bump up the
> hrStorageAllocationUnits (to what?)
> 3. notification in README.solaris and README about problem with HRM.
> We don't control the MIB so we can't fix it.
> 4. Modify the value of hrStorageAllocationUnits on the fly based upon
> the full size of the partition. If the potential exists to go bigger
> than we can handle, increase hrStorageAllocationUnits appropriately
> Does that sound reasonable?
Are you proposing four alternatives (and we should pick one),
or four complementary steps (and we should use some/all of them)?
It's certainly worth documenting the issue of lreporting on arge disks in
README. This doesn't feel like an inherently Solaris-specific problem.
Proposals 2 and 4 feel like alternatives - both to each other, and to
my two suggestions. I'm somewhat dubious about introducing this
sort of change so late in the release cycle, unless we can come up
with something very simple.
I can't sensibly comment on Proposal 1, since I don't the faintest idea
what this is about.....
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Net-snmp-coders mailing list