Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
Hi - wonder if someone could with getting my cacti install to show Disk Space for very large partitions. Got a host with a "/" partition total size of 120G which is showing fine. But our "/data" partition which is 21T shows as a 1.88G partition when using "ucd/net - Get Monitored Partitions" or 4.0T when using "SNMP - Get Mounted Partitions"?
Platform details are:
Cacti Version - 0.8.7d Plugin Architecture - 2.4 Poller Type - Cactid v Server Info - Linux 2.6.18-92.1.22.el5 Web Server - Apache/2.2.3 (CentOS) PHP - 5.1.6 PHP Extensions - libxml, xml, wddx, tokenizer, sysvshm, sysvsem, sysvmsg, standard, SimpleXML, sockets, SPL, shmop, session, Reflection, pspell, posix, mime_magic, iconv, hash, gmp, gettext, ftp, exif, date, curl, ctype, calendar, bz2, zlib, pcre, openssl, apache2handler, dbase, gd, memcache, mssql, mysql, mysqli, PDO, pdo_mysql, pdo_sqlite, snmp MySQL - 5.0.77-log RRDTool - 1.3.8 SNMP - 5.3.2.2 Plugins
Ideally I'd like to know if there is a command line way to verify the size being returned and is there a setting somewhere within the query that is limited the size of the partition being seen?
Please see 4th link of my sig to find an alternate way of doing this. Purely SNMP, but not tested against such large devices as I do not own any of them
R.
Thanks - tried that and it gave the same results, the /data partition is reported with a Total size of 4.40T. The host itself is nothing unusual, a Centos server with a couple of disk shelves to make up the 21T partition. I'll take a look at the SNMP stuff and see if I can get anything from that.
Yea, this one's been around for some time and I think there was a post relative to the whole thing being a snmp related issue and a bit beyond our control. But you have my attention at the moment.
TheWitness
True understanding begins only when we realize how little we truly understand...
Do me a favor, walk the entire tree (your whole device) and let's see what we get. I see what is happening. Note the following:
Total Disk Space = (2e32 + 1074233344) * 4096 ~ 21TBytes
So, the counter rolled over one complete rotation and then added 1074233344 on to it. So, there is likely another non-standard OID that tracks the number of times the counter has rolled over, in this case "1".
Were you walking with snmpv2 or snmpv1? If snmpv1, try snmpv2 for both requests.
TheWitness
True understanding begins only when we realize how little we truly understand...
Here is the open bug report from the Sourceforge.net bug databases for this problem. It shows open. Note the "truncate" warnings on the page. If those are happening client side, then we can fool the system the way I indicated. However, it's likely a hack.
To fix this, net-snmp must be patched. The net-snmp guys believe that the agent can support 64bit volumes np (real big). However, the way that the agent is behaving does not reflect this.
Before I go and fix net-snmp's agent, can you please update to 5.5, and see if the hrStorageAllocationUnits increases for this volume? If it does, and the problem goes away, then I know it's fixed.
My guess is not. When I talk upbout upgrading, it will be on the monitored node and not the Cacti server, ok? To me, the fix in the snmpd agent would be trivial, but I don't want to re-invent the wheel if it's already been done.
TheWitness
True understanding begins only when we realize how little we truly understand...