> Current hrStorageTable supports only 32bit hrStorageSize. With 4096 big > allocation units, it supports disks up to 16 TB. These sizes are > pretty common nowdays and I got few requests to do something about it. The > only thing which comes to my mind is to lie about hrStorageAllocationUnits > and report something bigger that 4096, so hrStorageSize fits into 32bits. > > This has obvious problems: > 1) we lie about allocation units. > 2) we loose few bits in precission of the total size of the device, > size * allocation units won't give real size of the drive but some > aproximation only. > > On the other hand, I think that something is better than completely broken > hrStorageSize for such devices.
Why not adopt a philosophy similar to the way that IF-MIB handled it? This is obviously not a one-off problem. In the next 5 to 10 years, this will be huge. Perhaps we add "hrHCStorageSize" which is a 64-bit integer (cf. "ifHCInOctets"). Or maybe "hrLargeStorageSize" which is measured in megabytes (cf. "ifHighSpeed"). These could go in "hrXStorageEntry" which would be defined as an extension table. What team/committee is responsible for the HOST-RESOURCES MIB? ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
