On 15 March 2010 20:58, Jeff Gehlbach <je...@opennms.org> wrote:
> About sixteen months ago I created issue 2340904 in the tracker describing an 
> Integer32
> overflow problem with the non-perentage objects in the dskTable when the 
> filesystems
> they represent are 2TB in size or larger.  There's been a burst of 
> conversation now and
> then, but no strong consensus on what to do about the problem.

I'll have a proper look at this tracker entry tomorrow.
But my immediate reaction would be as follows:

  -  the existing (Integer32) MIB objects should probably latch at the
maximum value,
      with the MIB description being updated to report this behaviour.
      These objects would then be effectively useless for large disks,
      but at least would not be positively misleading.

This feels more sensible than the wrapping approach of the ifHC Counters.
Those naturally wrap anyway, while these are guage values.
This is a change which could probably be applied to all active branches.

 -  introduce new "high capacity" versions of these MIB objects
      perhaps counting in Mb (or Gb?) rather than Kb, or else using the
      hrStorageTable approach of paired Value/Units objects

The paired MIB object approach is more flexible, whereas having fixed
units is probably simpler to use in practise.


  -  regardless of how the Net-SNMP-specific tables handle this,
  the hrStorageTable MIB structure is able to handle such large
  disks in a sensible manner.   We should ensure that the code
  does so, by varying the Units as appropriate.
  (I'm not sure whether it currently does or not)

Dave

------------------------------------------------------------------------------
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-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to