Used disk space graph problems with large ext4 volume.

[3dlover]

Hi there,
I have an ext4 volume that is about 10TB in size (10,095,105,760 1K blocks). My Cacti graph for Used Space on this volume shows 0 (zero) for the Total size, and I'm afraid that as I fill the volume up, the currently working Used value will change to 0. I assume that this is because the value is exceeding a 32bit register. This volume is not on the same machine as Cacti, so it's using ss_host_disk.php to query the values. I ran the ss_host_disk.php manually and can confirm that it is reporting all the correct values except for the Total size of this volume, in which case it returns a 0.

I don't know enough about how ss_host_disk.php works to know where the problem is, or why the number is being returned as 0. Interestingly enough, if I do an snmpwalk on both the machine with the 10TB volume and with the remote machine that has Cacti, I get different values for the hrStorageSize:

Machine with the 10TB volume locally mounted:

Code: Select all

# >uname -a
Linux hue 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux
# >snmpwalk -v 2c -c public localhost | grep -i hrStorage | grep .35
truncating signed value to 32 bits (1)
HOST-RESOURCES-MIB::hrStorageIndex.35 = INTEGER: 35
HOST-RESOURCES-MIB::hrStorageType.35 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.35 = STRING: /mnt/md2
HOST-RESOURCES-MIB::hrStorageAllocationUnits.35 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageSize.35 = INTEGER: 2523776440
HOST-RESOURCES-MIB::hrStorageUsed.35 = INTEGER: 1672416781

Remote machine that runs Cacti:

Code: Select all

# >uname -a
Linux polychrome 2.6.24-21-server #1 SMP Wed Oct 22 00:18:13 UTC 2008 i686 GNU/Linux
# >snmpwalk -v 2c -c public 192.168.111.9 | grep -i hrStorage | grep .35
HOST-RESOURCES-MIB::hrStorageIndex.35 = INTEGER: 35
HOST-RESOURCES-MIB::hrStorageType.35 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.35 = STRING: /mnt/md2
HOST-RESOURCES-MIB::hrStorageAllocationUnits.35 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageSize.35 = INTEGER: 841260716
HOST-RESOURCES-MIB::hrStorageUsed.35 = INTEGER: 1672424447

I don't know if this difference is a contributing factor to the incorrect value that ss_host_disk.php is reporting. Has anyone else tried to graph such a large volume before?

-Ray

[gandalf]

No, at least not with ext4.
Please try my pure SNMP replacement at 4th link of my sig and see if that helps
Reinhard

[3dlover]

I downloaded hrstoragetable087d.tar.gz from here: http://docs.cacti.net/usertemplate:data ... disk_usage

I extracted the hrStorageTable.xml to /usr/share/cacti/site/resource/snmp_queries/, but when I try to import the cacti087d_data_query_snmp_-_hrstoragetable.xml into cacti, I get the error message:
Error: XML: Hash version does not exist.

Any idea what is wrong? I'm using Version 0.8.7b, which is the most current in the Ubuntu LTS 8.04.

-Ray

[gandalf]

Indeed, you need to upgrade. This should be done apart from your current problem because of a lot of bug fixes done for 087d
Reinhard

[msafford]

I'm currently running 0.8.7d, and I'm also having problems getting data for large disks. However, this looks like an snmp issue, rather than a cacti-specific one.

Here's the data from an snmpwalk:

[[USER]@[CACTIHOST] ~]$ snmpwalk -v2c -c [COMMSTR] [HOST] HOST-RESOURCES-MIB::hrStorage | grep .22
HOST-RESOURCES-MIB::hrStorageIndex.22 = INTEGER: 22
HOST-RESOURCES-MIB::hrStorageType.22 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.22 = STRING: /backup
HOST-RESOURCES-MIB::hrStorageAllocationUnits.22 = INTEGER: 512 Bytes
HOST-RESOURCES-MIB::hrStorageSize.22 = INTEGER: 1006190592
HOST-RESOURCES-MIB::hrStorageUsed.22 = INTEGER: 415866636

Now, when I try an snmpget for the specific data:

[[USER]@[CACTIHOST] ~]$ snmpget -v2c -c [COMMSTR] [HOST] HOST-RESOURCES-MIB::hrStorageUsed.22
HOST-RESOURCES-MIB::hrStorageUsed.22 = INTEGER: 0

So, where's the value of 415866636 coming from? Well, when I check the hrStorageUsed for the preceeding index:

HOST-RESOURCES-MIB::hrStorageUsed.21 = INTEGER: 416400488
HOST-RESOURCES-MIB::hrStorageUsed.22 = INTEGER: 416400488

And I KNOW that these two disks have drastically different utilization levels.

I'm working on a solution based on calling a script via SNMP, but I'm unsure how to get Cacti to treat a string as a 64-bit unsigned integer.

[gandalf]

So, where's the value of 415866636 coming from? Well, when I check the hrStorageUsed for the preceeding index:

HOST-RESOURCES-MIB::hrStorageUsed.21 = INTEGER: 416400488
HOST-RESOURCES-MIB::hrStorageUsed.22 = INTEGER: 416400488

And I KNOW that these two disks have drastically different utilization levels.

This looks like a net-snmp bug. Please post to the net-snmp-users mailinglist

I'm working on a solution based on calling a script via SNMP, but I'm unsure how to get Cacti to treat a string as a 64-bit unsigned integer.

Cacti interprets those strings as numbers. It does not take care of snmp data types, it always tried to get numbers. But don't ask me, if e.g. spine uses signed integers. That's a question for Larry
Reinhard