Hi Dave, Thanks for the long response! Let me touch back on it. When I said counter I wasn't thinking- it is indeed an integer32. And you are correct in that AllocatedUnit * storageSize can accommodate a larger disk size.
You mentioned something that I have a question about (which also leads to my potential misunderstanding of the situation). My knowledge of AllocatedUnits is the block size of the disk. I said that it can't handle a very large disk because of the AllocatedUnits being locked to block size and not a custom scale factor. Is this wrong? Does AllocatedUnits not HAVE to be block size? Another note: when I said it wrapped the counter I meant it wrapped the Integer (You can pretty much replace counter with integer everywhere I said it). This does indeed happen on our devices. I looked into the 'dskTable' a bit. I upgraded a dev box from 5.5 to the latest release for testing purposes. I attempted to use the 'includeAllDisks' flag in order to have all of our disks available on-the-fly. This unfortunately didn't work. In the cases where our disks are large, maybe the best route for us would be for them to add a: 'disk DISKNAME' To our Snmpd.conf file? Thanks and sorry for confusing some of my facts earlier. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Shield Sent: Thursday, March 01, 2012 3:55 AM To: Day, Robert Cc: [email protected] Subject: Re: How does the hrStorageTable handle very large disks (> 20tb, for instance). On 29 February 2012 16:59, Day, Robert <[email protected]> wrote: > I've been dealing with this problem for some time. We have some large > disks here that cannot be measured accurately in the hrStorageTable > due to a 32 bit integer being too small. That's not strictly true. The hrStorageTable uses two column objects to represent the size of a disk partition (or other storage element) - hrStorageSize and hrStorageAllocationUnits. Both of these are 32-bit values, but in combination can handle elements up to 2^64 (16 exabytes) If hrStorageAllocationUnits is fixed at 1 (i.e. individual bytes), or 1024 (i.e. measured in K), then this will limit hrStorageSize and similar to 2^32 = 2 Gb or 2^42 = 2 Tb respectively. But the hrStorageTable can handle larger disks quite happily, and more recent versions of the Net-SNMP agent are starting to take advantage of this. > I understand that when the value is too large, it raps the counter. That is true of counter-based objects - but that's not really relevant here. The only counters in the Host Resources MIB are two error counters (hrStorageAllocationFailures and hrDeviceErrors). The size metrics are simple Integer values - probably the most sensible behaviour on overflow would be to latch at the maximum value. (See the description of Gauge objects in SMI) > Does net-snmp have any mib available similar to the hrStorageTable > that shows disk logical disk information with 64 bit counters? a) Forget about counters - they're not relevant here b) The hrStorageTable can already handle larger disks - see above c) The Net-SNMP specific 'dskTable' has entries which *are* limited to 2Tb (i.e. 32-bit values, measured in Kb) namely dskTotal, dskAvail and dskUsed. However these are accompanied by equivalent "paired" objects dskTotal{High,Low}, dskAvail{High,Low} and dskUsed{High,Low} which provide 64-bit representations (again measured in Kb), and so will handle disks up to 2 Zettabytes. That should be sufficient for the forseeable future! Dave ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
