'[Net-snmp-patches] [ net-snmp-Patches-2340904 ] dskTable: dskTotal'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-patches
Subject:    [Net-snmp-patches] [ net-snmp-Patches-2340904 ] dskTable: dskTotal
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2010-03-17 16:46:21
Message-ID: E1NrwNx-0001st-H1 () sfs-web-7 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]

Patches item #2340904, was opened at 2008-11-25 00:51
Message generated for change (Settings changed) made by dts12
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: Closed
> Resolution: Fixed
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: Jeff Gehlbach (jgehlbach)
Date: 2010-03-16 15:05

Message:
It appears Jan Safranek added the three pairs of high / low objects last
January in r17361. Robert Story also reports (in this -coders thread
http://comments.gmane.org/gmane.network.net-snmp.devel/20913) that the
5.4.3 release candidates appear to have protections against overflows in
these objects.

As far as I'm concerned, these two changes constitute a resolution to this
issue as of 5.5. The bug marshals are invited to mark this issue as
resolved!

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

Comment By: Robert Story (rstory)
Date: 2010-03-15 21:39

Message:
note that 5.5 and on have a fix for this, along with a new object
dskTotalHigh for the truncated value... so a fancy manager could do the
math to come up with the complete 64bit value..

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

Comment By: Robert Story (rstory)
Date: 2010-03-15 19:35

Message:
> 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?

I vote for this option.. as it's what the host resources mib should be
doing anyways, and hopefully the code could be used for both places.. I'm
on the fence on Counter64, as I hate to do it when we know better, but then
using a proprietary type is even worse.

Also, I'm not bit on a string object to represent the text for other
objects..

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

Comment By: Jeff Gehlbach (jgehlbach)
Date: 2010-01-24 20:40

Message:
Since nobody has commented on Wes' thoughts and this issue has come up at
least once more since I reported it, here's a response:

> 1) counter64 isn't the right type to use. Counters are defined in
meaning
> only by deltas.

Yep, the IETF could have helped us all by defining a Gauge64 in the
SMIv2.

> 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.

Cisco has done the same in at least the CISCO-ENHANCED-SLB-MIB. In my
particular case and that of our users and customers, the manager is
OpenNMS, which has long allowed a counter to be treated as a gauge because
there are quite a few MIBs out there whose authors didn't know the
difference. Using a c64 will solve the problem from my perspective.

> 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.

An opaque type will do nothing for us or our users and customers. It may
have value for others, of course.

> options:
> 1) apply as is.
> 2) apply and change to opaque int64

How about a solution that's "country AND western"?  Fix the existing
gauges so they don't overflow, mark them as deprecated, and add both c64
and uint64-opaque versions. That way, managers like OpenNMS that are happy
treating a c64 as a gauge will be happy, and managers that cannot
reinterpret a counter but can be told how to digest the Net-SNMP uint64
opaque type won't be left out.

If this proposal is accepted, I'll need a little direction since I've
never implemented an opaque variable in Net-SNMP.

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

Comment By: Wes Hardaker (hardaker)
Date: 2009-06-12 00: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 22:05

Message:
moving to patches

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

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

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

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

Comment By: Jeff Gehlbach (jgehlbach)
Date: 2009-05-05 21: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

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-patches mailing list
Net-snmp-patches@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-patches


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic