我们在Windows存储服务器上的5 TB卷上空间不足，因此我们将数据复制到新的10 TB卷中。
现在我们基于nagios的监测报告了我不满意的数据。 当我查看数据时，我注意到它报告了卷的总空间的负值。
起初，我假定caching问题，但我自己的方式通过snmpwalk手动查找值。 结果是：
iso.3.6.1.2.1.25.2.3.1.1.6 = INTEGER: 6 iso.3.6.1.2.1.25.2.3.1.2.6 = OID: iso.3.6.1.2.1.25.2.1.4 iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "V:\\ Label:VolumeXYZ Serial Number f6435543" iso.3.6.1.2.1.25.2.3.1.4.6 = INTEGER: 4096 iso.3.6.1.2.1.25.2.3.1.5.6 = INTEGER: -1610614235 iso.3.6.1.2.1.25.2.3.1.6.6 = INTEGER: 1163527892 iso.3.6.1.2.1.25.2.3.1.7.6 = Counter32: 0
鉴于所有其他卷在iso.3.6.1.2.1.25.2.3.1.5分支报告正值，我假设在这里看到一个负值的问题，是一个指标，为什么我看到一个在nagios的负值。
我该如何纠正这种情况？
负数是因为用于报告块数的有符号的32位整数的整数溢出。
我在基于Linux的NAS上遇到了同样的问题。 我能够在Linux中伪造一个更大的块大小，从而防止了整数溢出，并且块大小×块数产生了正确的存储量。 这个bug报告给Net-SNMP，并且有一个可用的补丁 。 我不确定你是否能够以相同的方式调整Windows系统。