The company's server hard disk is 44 TB and only 2 TB is captured using snmpwalk. See the red font below.
[Email protected]: # snmpwalk-V 2C-C *********. 1.3.6.1.4.1.2021.9.1.6
Iso.3.6.1.4.1.2021.9.1.6.1 = integer: 226311584
Iso.3.6.1.4.1.2021.9.1.6.2 = integer: 0
Iso.3.6.1.4.1.2021.9.1.6.3 = integer: 0
Iso.3.6.1.4.1.2021.9.1.6.4 = integer: 10240
Iso.3.6.1.4.1.2021.9.1.6.5 = integer: 0
Iso.3.6.1.4.1.2021.9.1.6.6 = integer: 6608132
Iso.3.6.1.4.1.2021.9.1.6.7 = integer: 5120
Iso.3.6.1.4.1.2021.9.1.6.8 = integer: 25716020
Iso.3.6.1.4.1.2021.9.1.6.9 = integer: 2147483647
Use DF-hl to view the information as follows:
Filesystem size used avail use % mounted on
/Dev/SDB 44 t 13 Gb 42 t 1%/Data
This problem occurs when the disk size exceeds 16 TB by querying relevant information.
When SNMP creates a MIB database, the table index is of the integer32 type, which leads to an error.
2147483647 = 2 ^ 31 (the maximum limit of a signed 32 bit integer (2147483647). If this value is exceeded, it is displayed as 2147483647. SMI defines a certain number of data types returned by OID. There is an integer, signed 32bit INTEGER (values between-2147483648 and 2147483647). A signed 32-bit integer (value range:-2147483648-+ 2147483648)
This bugredhat already has instructions, see: https://bugzilla.redhat.com/show_bug.cgi? Id = 654384
This article details in detail: In new net-snmp release it does not wrap at 2 ^ 31 but sticks to it if the real value is higher, I. e. reports 2147483647 for all devices bigger than 2 billion of allocation unit (instead of reporting 'size modulo 2 ^ 21 ').
RedHat has fixed this bug as follows: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/5.7_Technical_Notes/net-snmp.html#RHBA-2011-1076
Description:
BZ #654384.
Previusly, the snmpd daemon strictly implemented RFC 2780. however, this specification no longer scales well with modern big storage devices with small allocation units, and consequently, snmpd reported a wrong value of the HOST-RESOURCES-MIB :: hrstoragesize object when working with a large file system (larger than 16 TB), because the accurate value wocould not fit into integer32 as specified in the RFC. to address this issue, this update adds a new option to the/etc/snmp/snmpd. conf configuration file, realstorageunits. by changing the value of this option to 0, users can now enable recalculating all values in hrstoragetable to ensure that the multiplication of hrstoragesize and hrstorageallocationunits always produces an accurate device size. on the other hand, the values of hrstorageallocationunits are artificial and do not represent the real size of the allocation unit on the storage device.
This article from "My Struggle" blog, please be sure to keep this source http://wangmukun.blog.51cto.com/651644/1560333
An error occurred while capturing the disk capacity information of a remote server using SNMP.