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 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 (how?) 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 problem 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. http://sourceforge.net/powerbar/db2/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
