From: SourceForge.net <no...@so...> - 2009-05-05 21:05:30
|
Patches item #2340904, was opened at 2008-11-25 01:51 Message generated for change (Comment added) made by tanders 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: Thomas Anders (tanders) Date: 2009-05-05 23:05 Message: moving to patches ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 23:00 Message: Bumping priority. Apologies if this goes against project conventions. ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 22: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 |
From: SourceForge.net <no...@so...> - 2009-06-11 23:35:02
|
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 |
From: SourceForge.net <no...@so...> - 2010-01-24 20:40:32
|
Patches item #2340904, was opened at 2008-11-24 19:51 Message generated for change (Comment added) made by jgehlbach 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: Jeff Gehlbach (jgehlbach) Date: 2010-01-24 15: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-11 19: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 17:05 Message: moving to patches ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 17:00 Message: Bumping priority. Apologies if this goes against project conventions. ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 16: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 |
From: SourceForge.net <no...@so...> - 2010-03-15 19:35:35
|
Patches item #2340904, was opened at 2008-11-24 19:51 Message generated for change (Comment added) made by rstory 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: Robert Story (rstory) Date: 2010-03-15 15: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 15: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-11 19: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 17:05 Message: moving to patches ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 17:00 Message: Bumping priority. Apologies if this goes against project conventions. ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 16: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 |
From: SourceForge.net <no...@so...> - 2010-03-15 21:39:41
|
Patches item #2340904, was opened at 2008-11-24 19:51 Message generated for change (Comment added) made by rstory 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: Robert Story (rstory) Date: 2010-03-15 17: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 15: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 15: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-11 19: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 17:05 Message: moving to patches ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 17:00 Message: Bumping priority. Apologies if this goes against project conventions. ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 16: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 |
From: SourceForge.net <no...@so...> - 2010-03-16 15:05:14
|
Patches item #2340904, was opened at 2008-11-24 19:51 Message generated for change (Comment added) made by jgehlbach 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: Jeff Gehlbach (jgehlbach) Date: 2010-03-16 11: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 17: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 15: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 15: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-11 19: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 17:05 Message: moving to patches ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 17:00 Message: Bumping priority. Apologies if this goes against project conventions. ---------------------------------------------------------------------- Comment By: Jeff Gehlbach (jgehlbach) Date: 2009-05-05 16: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 |
From: SourceForge.net <no...@so...> - 2010-03-17 16:46:21
|
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 |