[ net-snmp-Bugs-1743171 ] 5.4 hrStorageSize overflow on large filesystems

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1743171, was opened at 2007-06-25 23:01
Message generated for change (Comment added) made by bcandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1743171&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: agent
Group: solaris
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ed Ravin (eravin)
Assigned to: Nobody/Anonymous (nobody)
Summary: 5.4 hrStorageSize overflow on large filesystems

Initial Comment:
Platform is a Solaris 10 box with a very large filesystem:

# df -h /export
Filesystem             size   used  avail capacity  Mounted on
Export                 1.2T   3.8G   1.1T     1%    /export
# df -k /export
Filesystem            kbytes    used   avail capacity  Mounted on
Export               1261338624 4032640 1139000439     1%    /export

Agent is Net-SNMP 5.4.  A walk of hrStorage for this filesystem looks like
this:

HOST-RESOURCES-MIB::hrStorageIndex.36 = INTEGER: 36
HOST-RESOURCES-MIB::hrStorageType.36 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.36 = STRING: "/export"
HOST-RESOURCES-MIB::hrStorageAllocationUnits.36 = INTEGER: 512 Bytes
HOST-RESOURCES-MIB::hrStorageSize.36 = INTEGER: -2008937171
HOST-RESOURCES-MIB::hrStorageUsed.36 = INTEGER: 8065273
HOST-RESOURCES-MIB::hrStorageAllocationFailures.36 = Counter32: 0

What's with the negative numbers in hrStorageSize?  Wait a minute, the MIB
for hrStorageSize says:

     SYNTAX     Integer32 (0..2147483647)

and I'd expect the val to be: 2522677248 (size in kbytes * 2 = size in 512b blocks)

so this is an overflow of Integer32?  Why is disk size a signed value?

----------------------------------------------------------------------

Comment By: Brian Candler (bcandler)
Date: 2011-10-25 15:01

Message:
I have a different symptom with net-snmp 5.4.2 from Ubuntu 11.04. Instead
of getting a negative hrStorageSize, I get the value from the previous row.

$ snmpwalk -v2c -cpublic x.x.x.x hrStorageTable | grep '\.3[34] = '
HOST-RESOURCES-MIB::hrStorageIndex.33 = INTEGER: 33
HOST-RESOURCES-MIB::hrStorageIndex.34 = INTEGER: 34
HOST-RESOURCES-MIB::hrStorageType.33 = OID:
HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.34 = OID:
HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.33 = STRING: /dev
HOST-RESOURCES-MIB::hrStorageDescr.34 = STRING: /media/data
HOST-RESOURCES-MIB::hrStorageAllocationUnits.33 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.34 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageSize.33 = INTEGER: 3089665
HOST-RESOURCES-MIB::hrStorageSize.34 = INTEGER: 3089665        <<<< OOPS!
HOST-RESOURCES-MIB::hrStorageUsed.33 = INTEGER: 162
HOST-RESOURCES-MIB::hrStorageUsed.34 = INTEGER: 651026208

This disk appears to have a utilisation of 20000% if you divide
hrStorageUsed by hrStorageSize.

Unfortunately while a negative value can be corrected by adding 2^32, a
completely wrong value is unusable.

Also reported at
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/865268

Aside regarding the MIB definition: the value returned in the SNMP
response is explicitly tagged as a signed integer, and so it doesn't matter
what the MIB says. For example, tcpdump shows 02 04 da 47 df 7f. The 02 =
tag 2 = signed integer; 04 = number of bytes of data; da47df7f = value,
which is negative.

----------------------------------------------------------------------

Comment By: Pete_C (peter_clapham)
Date: 2007-12-03 13:16

Message:
Logged In: YES 
user_id=1708781
Originator: NO

This is a common issue with disks > 2TB.

Apparently a patch has been provided but no update as yet if it is likely
to be included with next update.

Further details are available here:

http://archives.devshed.com/forums/networking-100/wrong-values-in-disk-statistics-for-diskslarger-then-2tbt-2092154.html#post7074342

----------------------------------------------------------------------

Comment By: Ed Ravin (eravin)
Date: 2007-06-26 07:10

Message:
Logged In: YES 
user_id=21104
Originator: YES

Oh, I see this is more or less the same issue as 1445722.

----------------------------------------------------------------------

Comment By: Ed Ravin (eravin)
Date: 2007-06-26 05:33

Message:
Logged In: YES 
user_id=21104
Originator: YES

Same results with 5.4.1-pre3.  I believe the problem is the MIB
definition:

hrStorageSize OBJECT-TYPE            
    SYNTAX     Integer32 (0..2147483647)
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "The size of the storage represented by this entry, in
        units of hrStorageAllocationUnits. [...]

If the agent thinks that HRStorageAllocationUnits is 512 bytes, that means
the value it
should put in hrStorageSize for my large filesystem is 2522677248, so it
overflows Integer32.

Would it be against the rules to teach the agent to lie about
hrStorageAllocationUnits?  It could kepp doubling hrStorageAllocationUnits
until hrStorageSize fits into an Integer32.  That would future-proof the
MIB as long as clients didn't make any rash decisions based on
hrStorageAllocationUnits.

The UCD MIB object dskTotal has a similar problem - it assumes all values
are in kbytes, so it works for my 1.2 terabyte system but will fail on a
filesystem that is larger than 2147483647 kbytes (~2.1 terabytes).

It seems like neither of the two disk space MIBS will currently work for
multi-terabyte filesystems.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2007-06-25 23:06

Message:
Logged In: YES 
user_id=848638
Originator: NO

Can you re-test with 5.4.1.pre3 and report back, please?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1743171&group_id=12694