[Net-snmp-patches] [ net-snmp-Patches-2340904 ] dskTable: dskTotal / dskAvail / dskUsed overflow-prone

[SourceForge.net <no...@so...>]

Patches item #2340904, was opened at 2008-11-24 16:51
Message generated for change (Comment added) made by hardaker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=2340904&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeff Gehlbach (jgehlbach)
Assigned to: Nobody/Anonymous (nobody)
Summary: dskTable: dskTotal / dskAvail / dskUsed overflow-prone

Initial Comment:
The columnar objects dskTotal, dskAvail, and dskUsed from the dskTable of the UCD-SNMP-MIB are increasingly prone to wrapping as multi-terabyte volumes become commonplace.  I would like to propose amending this table with nine new objects to extend its useful lifetime:

dsk{Total,Avail,Used}High: Unsigned32, high-order 32 bits of actual value
dsk{Total,Avail,Used)Low: Unsigned32, low-order 32 bits of actual value
dsk{total,Avail,Used}Str: DisplayString, decimal string representation of actual value

I'm willing and able, time permitting, to hack on this if needed.

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

>Comment By: Wes Hardaker (hardaker)
Date: 2009-06-11 16:34

Message:
Quick thoughts:

1) counter64 isn't the right type to use.  Counters are defined in meaning
only by deltas.  That being said, the IETF has used c64s in this way in one
of their MIBs so maybe it's ok.  I worry about manager code that doesn't
treat it as a raw number.  But then, I don't know any managers that at
least won't show you the value even when it's a counter.
2) A better type would actually be the UINT64 type that we support (an
opaque derivative).  Of course, because Net-SNMP is the only implementation
of it then it brings a similar problem: not every manager will treat it the
same.

options:
1) apply as is.
2) apply and change to opaque int64
3) use a string (bzzzz  not a good solution)
4) define the new objects as uint64 but with a different units type like
MB instead of KB.  That leaves us supporting up to 4294TB sizes.  I suspect
we're sufficient far away from that?

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

Comment By: Thomas Anders (tanders)
Date: 2009-05-05 14:05

Message:
moving to patches

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

Comment By: Jeff Gehlbach (jgehlbach)
Date: 2009-05-05 14:00

Message:
Bumping priority. Apologies if this goes against project conventions.

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

Comment By: Jeff Gehlbach (jgehlbach)
Date: 2009-05-05 13:59

Message:
I've attached a patch against the 5.4.2.1 Subversion tag that compiles
cleanly and works as expected for the case of Linux 2.6 on i386. My testing
is far from exhaustive since I currently lack the time to test on x86_64 or
any other platforms, and do not have access to a test system with any
filesystems >= 2TB in size.

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

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