This is a discussion on RE: net-snmp 5.4 and very large filesystems - SNMP ; 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. Proposed solution: 1. nasty hack to allow LARGEFILE support not to trigger the ...
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.
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?
I reported it as bug 1743171 on Sourceforge. After researching it
some more I realized that the bug is in the hrStorage MIB definition -
they use an Integer32 for the disk size, and since the disk size is
in units of hrStorageAllocationUnits, which on Solaris ZFS is 512 bytes,
any file system larger than 1099511627264 bytes will cause a negative
value to appear in hrStorageSize. A smart client can deal with the
by adding 2^32 to any negative values found in hrStorageSize, but that
only gets us to filesystems of 2199023255040 bytes. After that, the
current hrStorage MIB is useless, unless the agent fudges the
hrStorageAllocationUnits to be larger so that it can provide a number
within the Integer32. I'd like to know why the hrStorage MIB designers
thought filesystem size should be represented by a signed value...
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
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