摘要

  • RFC 1514 的 hrStorageTable 记录有固定资源上限的逻辑存储区，口径是请求方实际可用的量，而不是底层设备的原始容量。
  • hrStorageSize 与 hrStorageUsed 都以 hrStorageAllocationUnits 为单位；离开单位的整数不能直接当成字节数。
  • 设备、磁盘、分区、文件系统分别有自己的表，索引为零可以表示映射信息不可得，并不能证明背后没有存储。

先问“这个数在说什么”

设想一台早期工作站。磁盘控制器知道介质容量，操作系统知道分区，文件系统知道挂载点，应用只知道自己能否再取得一块空间。四个观察者面对同一台机器，却不必给出同一个数字。

差异有真实理由。格式化和文件系统引用信息占用介质，却不能被应用当作数据空间；配额可以把应用限制在更小的池里；交换空间与缓冲池具有存储功能，却不一定对应一块独立磁盘。若采集器把这些值都改名为“磁盘容量”，准确的原始记录会在展示层变成矛盾。

RFC 1514 的 Host Resources MIB 正是为跨平台管理而来。它不能要求个人电脑、Unix 系统和其他主机拥有相同的内部结构，于是采用概念表：共同规范不替本地系统发明一种唯一现实，只规定远端管理者必须如何理解暴露出来的对象。

逻辑池从申请者一侧定义

hrStorageTable 的描述十分具体。凡是已经分配、并有固定资源限制的逻辑存储区，都应有一行。该行表示“请求实体实际可用”的量，扣除格式化和文件系统引用信息造成的损耗。它接近应用看到的逻辑空间，而不是操作系统通常看到的物理存储实体。

这意味着容量不是脱离关系的属性。物理介质上的元数据扇区没有消失，只是退出了应用可分配的口径。底层磁盘还有空闲，也不代表某个受限池还能扩张。内存区、交换空间、缓冲池同样可以进入这张表，因为关键条件是“按块向请求方分配”，而不是“长得像磁盘”。

反过来，没有文件系统的磁带或软盘通常不应仅凭物理存在就进入表中。它们未必由操作系统按块分给应用。RFC 1514 选择的是一种分配关系，而不是一份机箱资产清单。

少了单位，容量就只剩坐标

每一行还必须给出 hrStorageAllocationUnits，说明一个分配对象包含多少字节。若资源按扇区、块、缓冲区甚至包来计量，该值往往大于一。hrStorageSize 与 hrStorageUsed 保存的都是这种单位的数量。

只有将数量乘以单位，才能得到所表示的字节数。采集器若留下 hrStorageSize 却丢掉 hrStorageAllocationUnits，保存的不是容量，只是一个失去比例尺的坐标。若同一行的单位发生变化，监控系统仍机械连接前后整数，还会制造出并不存在的容量突变。

这种设计没有强迫所有主机按字节分配。共同层只规定成对解释的方法，本地实现仍可采用符合自身运行方式的块大小。这正是最小共同规范发挥作用的地方：互操作需要明确语义，不需要中央决定每台机器如何分配存储。

物理设备没有被藏起来

RFC 1514 另外设置了设备表，并为处理器、网络接口、打印机和磁盘等设备建立细分表。磁盘表描述长期存储设备，容量以千字节报告。分区和文件系统也各有自己的身份与字段。

这些层可以关联，却不是天然一一对应。hrPartitionFSIndex 在分区没有文件系统、或者文件系统信息不可得时可以为零。hrFSStorageIndex 从本地文件系统指向能够说明占用比例和空间耗尽的逻辑存储行；没有这种信息时同样为零。

零不是一张“无盘证明”。它只说当前管理视图没有提供可用关联。远端系统为了画出完整拓扑而猜一个索引，会得到更漂亮的图，也会把未知改写成事实。

拒绝次数也不是损失总账

hrStorageAllocationFailures 记录该逻辑池因为空间不足而无法满足请求的次数。它可以揭示某个池已经碰到上限，即使定时采样没有抓到峰值。但它不告诉管理者是哪一个进程、被拒绝多少字节、影响了多少用户、是否丢失数据、持续多久或后来是否恢复。

RFC 1514 还提醒：Counter 没有规定初始值，只是建议初始化为零。RFC 2790 把消费者的责任说得更清楚——管理站不能依赖这个初始化。因而一次孤立读数不能证明“自开机以来”的失败总量。只有确认计数处于连续纪元，前后差值才有明确用途。

容量字段定义池的边界，失败计数观察申请被拒绝的事件。二者不是彼此的替代品，更不能直接升级为业务结果。

可写语法不是授权书

RFC 1514 在介绍管理框架时已经说明，对象的访问级别表示读写在协议上是否有意义，它独立于行政授权政策。hrStorageSize 标为 read-write，并不等于任何能访问 SNMP 的管理者都获得调整磁盘的权力。

后继 RFC 2790 补充了操作边界：只有当调整对该存储区有意义、底层系统也确实支持时，写入才成立，例如改变缓冲池所占内存或交换空间所占磁盘。协议表达可能性，主机实现决定能力，授权机制决定谁能操作。这三层不能因一个“可写”标签而合并。

RFC 1514 的安全章节只说没有讨论安全问题。RFC 2790 则明确提醒，读取主机资源会暴露敏感配置和性能信息，可写对象还可能改变主机行为。标准的演进没有改变最初的分层，反而让控制边界更清楚。

七年后，逻辑层仍然存在

2000 年的 RFC 2790 废止并替代 RFC 1514，将模块转换到 SMIv2，同时保留了最关键的文字：逻辑存储区、有固定上限、请求方可实际使用、排除格式化损耗。分配单位、可为空的文件系统关联以及独立设备层也都继续存在。

这段延续说明，早期互联网管理追求的并非一张万能资产表。它要让不同主机在不放弃本地实现的前提下，向远端交付足够的解释结构。互操作来自类型、单位和关系的窄契约，而不是把所有数字压成“容量”。

今天的遥测系统仍面对同样选择。采集时必须让表示层、行身份、单位、关联与计数纪元跟着数字一起走。只要这些条件存在，物理供给、逻辑限制、文件系统可用量和拒绝事件可以被诚实比较。一旦条件被删掉，再高的小数精度也无法补回原来的含义。

来源