16TB卷和SNMP在Windows上
当大于16TB的卷变得越来越普遍时，人们认识到用于在SNMP中的标准“HOST-RESOURCES”MIB中报告磁盘大小和使用的32位值不足以报告正确的磁盘大小。
Net-SNMP似乎通过简单地操作“AllocationUnits”的值来维护磁盘利用率的32位值（因为总的磁盘大小/使用等于32位空间值乘以分配单位）来解决这个问题，以允许用于计算大于8 / 16TB的音量。 假设你在分配单元中没有任何报告兴趣，并且可能存在一小部分的不准确性。 这似乎是一个优雅的解决scheme。
https://bugzilla.redhat.com/show_bug.cgi?id=654384
然而，内置SNMP服务的Window似乎仍然受到这个错误的困扰，只是简单地报告了使用/分配的磁盘空间的模数，导致磁盘大小报告不准确。
有没有办法让Windows正确报告16TB以上卷的磁盘使用情况？ 我们试图简单地安装Net-SNMP 5.5 x64并完全禁用Windows SNMP服务，但是这不幸的是没有解决我们的问题。
当使用NetSNMP扩展时，我们为我们感兴趣的特定磁盘收集的信息如下：
无论我们是使用vanilla Windows SNMP服务还是使用NetSNMP，这些结果都是相同的。
我已经看到Cacti社区的人们提到了简单的脚本解决scheme。 不幸的是，我们正在使用Observium进行快速和基本的系统监控。 如果这个问题不能在窗口方面纠正，Observium是否可以报告自定义的MIB？
– 更新 –
查看bug报告中提到的将“realStorageUnits”添加到snmpd.conf文件中，设置该指令时遇到以下问题：
– 更新2 –
那么，经过多less修补之后，它看起来不像Net-SNMP的任何Windows版本，如“realStorageUnits”指令。 启动SNMP时，包括指令的结果将会出现警告。 我们尝试了版本5.5,5.6和5.7。 有没有人曾经想过如何让SNMP在Windows上报告16+ TB的卷？
前一段时间有一个 Net-SNMP 5.5 的补丁 ，为configuration文件引入了一个新的选项realStorageUnits 。
从Redhat Bugreport＃748410 ：
为了解决这个问题[negative hrStorageSite值]，这个更新为/etc/snmp/snmpd.confconfiguration文件realStorageUnits添加了一个新选项。 通过将此选项的值更改为0，用户现在可以重新计算hrStorageTable中的所有值，以确保hrStorageSize和hrStorageAllocationUnits的乘积总是能够生成准确的设备大小。
（[括号内的文字是我的]
因此，将configuration指令realStorageUnits 0添加到您的snmpd.conf中可能会解决您的问题。
但是，直到最后一兆字节，这些值都是不正确的。 因人而异。
我不知道这个补丁是否包含在你的Net-SNMP的二进制发行版中，但是如果你能够报告结果以及你正在使用什么二进制文件，那将是非常好的。 另外，我现在没有testing它缺乏足够的硬件。
我知道这不是直接回答你的问题，但也许会有所帮助。 我build议你尝试联系SNMP Informant的团队： http : //www.snmp-informant.com/
他们扩展Windows SNMP代理来解决微软对其OIDs的一些限制。 我和Zenoss一起使用它来获得更加准确的CPU利用率和存储数量，这很有可能解决你的问题，但我不能肯定地说。