Disk size greater than 2TB or 4TB, > 2 Tera Bytes, >2T

[D0li0]

I'm running Cacti Version 0.8.7b with SNMPv2 on and against a variety of platforms including Linux (Ubuntu & Debian), FreeBSD, and Windows (2000, XP, Vista).

The problem I'm encountering is with disks larger than 2TB or 4TB. I believe that the problem is due to the 16 bit values that are returned by "ucd/net - Get Monitored Partitions" or the 16 bit (unsigned? or something) values that are returned by "SNMP - Get Mounted Partitions". Surely there must be a simple solution for getting valid data back from large disks!? Is it possible to somehow set either of these Data Queries to return 32 bit or 64 bit values so they can support disks larger then 2TB or 4TB? Would that be done at the host, in the MIB, within cacti somewhere?

In the hopes that this topic will get more search hits, here are some more thing that people might search for. Whenever the free space, used space, total space, or available space exceeds one of these limits the returned value overflows or is a negative number and displays as "NaN". So the disk size limit is 2 or 4 TB.

I've also looked for solutions in by searching "disk size limit" and in:
http://forums.cacti.net/about23612.html
http://forums.cacti.net/about28222.html

per http://forums.cacti.net/about17533-0-asc-15.html
We started using hrStorageUsed (available in the standard template from Cacti under "SNMP - Get Mounted Partitions" in the data queries for a "ucd/Net SNMP host").
It works for larger filesystems however it's overflowing for our 12TB volume. I am trying to figure out how to work around that as we will rolling out 24TB volumes very soon and even a 44TB one too
snmpwalk -v SNMPVERSION -c COMMUNITYNAME HOST hrStorage

So I did this (which worked, until the disk usage passed 4TB at which point the same issue arises:
In Cacti console: (Host Templates) -> (ucd/net SNMP Host) -> in "Associated Data Queries" choose "SNMP - Get Mounted Partitions" [Add]
Then find the host with a large disk and add a graph for that disk.

If anyone has a solution, please share it with me and be as detailed as possible in the steps for implementing it as I'm not exactly an expert.

[D0li0]

So on the Linux and BSD systems I've found these files:
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt or /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt
and
/usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt or /usr/local/share/snmp/mibs/HOST-RESOURCES-MIB.txt

Which contain lines such as
DskEntry ::= SEQUENCE { ... dskX Integer32, ...
... Integer32 (0..2147483647)

I've tried changing the integer range, and changing the syntax type to "DisplayString" at both the cacti server and the host being queried but queries against these OIDs "hrStorage" or "DskEntry" continue to return overflow values like "INTEGER: -2147483648". So I don't think the changes I'm making in the files mentioned above are taking effect. I'm assuming that cacti would graph larger values if only the clients would return the proper responses... Is there an Integer64? Any ideas?

[D0li0]

Editing the file UCD-SNMP-MIB.txt on the cacti server and replacing "Integer32" with "Counter64" for the "dskUsed" field(s) results in:
UCD-SNMP-MIB::dskUsed.4 = Wrong Type (should be Counter64): INTEGER: -2147483648
I tried using Counter64 because it appears to be defined as "IMPLICIT INTEGER (0..18446744073709551615)" which should be about 18,446,744,073 TB TeraBytes ( 18,446,744 PB PetaBytes ( 18,446 EB ExaBytes (18 ZB ZetlaBytes)))? I'm probably making a mistake here somewhere. I also performed the same changes on the client and restarted it's snmpd service but that didn't change the results. Do I need to recompile the snmpd client of change these values somewhere else??

[gandalf]

Changing the MIB file does not help. The problem lies with the snmp agent on the target system
Reinhard

[D0li0]

Changing the MIB file does not help. The problem lies with the snmp agent on the target system

Are you aware of a solution or work around? Is there an alternate MIB that can be used which supports larger values? Is there something that I can change in the snmpd client source such that recompiling it will fix the issue? Any tips regarding where to look for such changes/patches. I believe all of my clients with large disks are running FreeBSD. I find it difficult to believe that there is not yet a solution for snmp to deal with large disks.

[gandalf]

This is not a cacti issue.
Usually, the work around is to define sth like a "block size" of let's say 4kb and count disk space in units of blocks. Increasing the block size, you will be able to reach higher numbers.
This must be implemented by the manufacturer of the device, if the current standard MIBs are exceeded.
Again, this is not a cacti issue; so I'm not able to help out creating any patch
Reinhard

[nileshmistry73]

Hello

Has there been any further development on this?

Nilesh

[D0li0]

Has there been any further development on this?

Nope, as Gandalf pointed out, and as I had suspected this isn't a problem with cacti. Rather it's a limitation of the old/standard snmpd MIB for reporting disk space which at the time probably didn't expect to ever see disks above 2 or 4 TB. I haven't found an acceptable solution yet as I don't want to change my disks block sizes. I think that it should be possible to define a new MIB that uses 32 or 64 bit values instead of 16 or that returns multiple 16 bit values so that it can support large disks. But I am not an snmpd expert, nor a cacti template expert so I haven't yet implemented such as solution. If I do I will be sure to post the solution here and elsewhere... If you find a solution first, please post it!

L8r
Ryan

[gandalf]

Please see http://forums.cacti.net/viewtopic.php?t=28713 for more discussion
Reinhard