最近有收到来自某市公交集团项目的运维人员反馈，说是有某台oracle服务器上的硬盘分区在zabbix监控平台上和实际的大小不符；这台机器记得当时是安装agent来监控的，但后面发生数据库由于不明原因崩了，领导为了不让其他进程占用资源，改为snmp方式监控。

后面登录监控系统查看数据，一对比，还真是不一致。左边是数据展示的表格，和zabbix的最新数据类似，右边是分区真实的大小。

以下是分区总大小的计算公式，以字节单位计算的，真实的分区大小×真实的可分配单元， last("hrStorageSize[{#SNMPVALUE}]") * last("hrStorageAllocationUnits[{#SNMPVALUE}]")

通过使用snmpwalk命令查看以下2个值，计算得到的也是7T左右。于是，接着排查 ......

后面一想，会不会是默认配置的原因，根据参考RFC 2790中的定义hrStorageSize是32bit整形，如果硬盘太大超过了他的表示范围。于是按照解决方法，在snmpd.conf配置后加多一行 realStorageUnits 0 ，重启，再重新检查数据，发现硬盘大小显示正常了！！！！！

以下是从snmp.conf官网找到的解释：

realStorageUnits

controlls how the agent reports hrStorageAllocationUnits, hrStorageSize and hrStorageUsed in hrStorageTable. With this option set to '0', the agent re-calculates these values for big storage drives with small allocation units so hrStorageAllocationUnits x hrStorageSize gives real size of the storage.

Example:

Linux xfs 16TB filesystem with 4096 bytes large blocks will be reported as hrStorageAllocationUnits = 8192 and hrStorageSize = 2147483647, so 8192 x 2147483647 gives real size of the filesystem (=16 TB).

Setting this directive to '1' turns off this calculation and the agent reports real hrStorageAllocationUnits, but it might report wrong hrStorageSize for big drives because the value won't fit into Integer32. In this case, hrStorageAllocationUnits x hrStor-ageSize won't give real size of the storage.

简单点就是说，如果 realStorageUnits 这里设置为 realStorageUnits 1 或者没有，那么就不会是计算真实的可分配单元，也就会看到的是错误的总大小，因为对于比较大的硬盘，最多不会超过32位。设置realStorageUnits 0 则会根据真实的情况计算硬盘的总容量。

参考文章：