Bug 1257161 - net-snmp reports wrong filesystem size
net-snmp reports wrong filesystem size
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: net-snmp (Show other bugs)
6.7
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Jan Safranek
BaseOS QE Security Team
:
: 1262944 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-26 07:50 EDT by Rikard
Modified: 2015-09-21 09:02 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-03 04:32:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
df output (501 bytes, text/plain)
2015-08-31 05:07 EDT, Rikard
no flags Details
snmpwalk from new net-snmp (4.08 KB, text/plain)
2015-08-31 05:08 EDT, Rikard
no flags Details
snmpwalk from old net-snmp (4.08 KB, text/plain)
2015-08-31 05:08 EDT, Rikard
no flags Details

  None (edit)
Description Rikard 2015-08-26 07:50:02 EDT
Description of problem:
After installing net-snmp-5.5-54.el6.x86_64 and net-snmp-libs-5.5-54.el6.x86_64 net-snmp reports 10TB ext4 filesystem as 2TB. downgrading to net-snmp-5.5-50.el6_6.1.x86_64 and net-snmp-libs-5.5-50.el6_6.1.x86_64 makes it report correct again. 

For some reason it did not work with net-snmp-5.5-54.el6.x86_64 and net-snmp-libs-5.5-54.el6.x86_64 either so the bug probably was introduced here. I cannot se the fault on filesystems   

Version-Release number of selected component (if applicable):
See above

How reproducible:
upgrade to net-snmp-5.5-54.el6.x86_64 and net-snmp-libs-5.5-54.el6.x86_64



Actual results:
10TB filesystem shows as 2TB filesystem

Expected results:
show as 10TB filesystem

Additional info:
I have not seen the error on servers with 6TB filesystems
Comment 1 Rikard 2015-08-26 07:54:55 EDT
It should have been the latest available version net-snmp-5.5-54.el6_7.1.x86_64 and net-snmp-libs-5.5-54.el6_7.1.x86_64 under "Description of problem" 

//Rikard
Comment 3 Jan Safranek 2015-08-27 12:04:50 EDT
This may be related to bug #1104293 (sorry, confidential) that we fixed in RHEL 6.7. Can you please post snmpwalk output with the bad numbers (=new net-snmp) and good numbers (=old net-snmp packages), together with `df` output?
Comment 4 Rikard 2015-08-31 05:07:16 EDT
Created attachment 1068549 [details]
df output
Comment 5 Rikard 2015-08-31 05:08:09 EDT
Created attachment 1068550 [details]
snmpwalk from new net-snmp
Comment 6 Rikard 2015-08-31 05:08:36 EDT
Created attachment 1068551 [details]
snmpwalk from old net-snmp
Comment 7 Jan Safranek 2015-08-31 10:09:50 EDT
The old net-snmp shows:
HOST-RESOURCES-MIB::hrStorageSize.37 = INTEGER: 2683487208

While the value is correct (2683487208 * hrStorageAllocationUnits gives size of the device), it's bad from SNMP protocol point of view. hrStorageSize must be  Integer32 (0..2147483647) and 2683487208 is higher than 2147483647. 

This caused several 3rd party clients to behave unexpectedly and therefore we fixed this bug in the latest Net-SNMP release - we report values lower than 2^31. To get real size of large drives, we introduced a new option 'realStorageUnits' couple of releases ago.

Add 'realStorageUnits 0' to your /etc/snmp/snmpd.conf. snmpd will then report artificial value of hrStorageAllocationUnits (probably 8k instead of 4k), so hrStorageAllocationUnits * hrStorageSize gives real size of the storage.

SNMP is really old protocol and they did not think about terabytes at that time...
Comment 8 Rikard 2015-09-03 03:25:57 EDT
(In reply to Jan Safranek from comment #7)
> The old net-snmp shows:
> HOST-RESOURCES-MIB::hrStorageSize.37 = INTEGER: 2683487208
> 
> While the value is correct (2683487208 * hrStorageAllocationUnits gives size
> of the device), it's bad from SNMP protocol point of view. hrStorageSize
> must be  Integer32 (0..2147483647) and 2683487208 is higher than 2147483647. 
> 
> This caused several 3rd party clients to behave unexpectedly and therefore
> we fixed this bug in the latest Net-SNMP release - we report values lower
> than 2^31. To get real size of large drives, we introduced a new option
> 'realStorageUnits' couple of releases ago.
> 
> Add 'realStorageUnits 0' to your /etc/snmp/snmpd.conf. snmpd will then
> report artificial value of hrStorageAllocationUnits (probably 8k instead of
> 4k), so hrStorageAllocationUnits * hrStorageSize gives real size of the
> storage.
> 
> SNMP is really old protocol and they did not think about terabytes at that
> time...

Thank you Jan now works to monitor the 10TB filesystems again. Using the new net-snmp-libs-5.5-54.el6_7.1.x86_64 and net-snmp-5.5-54.el6_7.1.x86_64 if the setting "realStorageUnits 0" is in /etc/snmp/snmpd.conf
Comment 9 Jan Safranek 2015-09-03 04:32:51 EDT
Thanks for the feedback. I am closing the bug now.
Comment 10 Jan Safranek 2015-09-21 09:02:18 EDT
*** Bug 1262944 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.