要約

  • RFC 1514のhrStorageTableは、物理装置の総容量ではなく、要求主体が利用できる固定上限付きの論理領域を表した。
  • hrStorageSizeとhrStorageUsedはhrStorageAllocationUnitsの個数であり、単位を失った整数はバイト数にならない。
  • 装置、ディスク、パーティション、ファイルシステムは別の表に置かれ、ゼロの索引は対応情報が得られない場合を含んだ。

容量表示が食い違う朝

管理端末には二つの値が並ぶ。一方はディスク装置の容量、もう一方はアプリケーションが使う論理領域の大きさだ。後者は小さい。フォーマットやファイルシステムの参照情報に使われる部分は、アプリケーションのデータとして配分できないからである。さらに、割当枠や仮想記憶の設定が境界を狭めているかもしれない。

ここで「小さい方が間違い」と決めれば、監視者が異なる測定対象を勝手に同一化したことになる。二つの値は同じ物体を別の精度で測ったのではない。それぞれ異なる問いに答えている。

Host Resources MIBは、個人用コンピューターからUnix系ホストまで共通に扱うために作られた。内部構造を一種類に統一することはできない。RFC 1514は概念表を用い、遠隔の管理者が数字の所属する層を判別できるようにした。

アプリケーション側から見た領域

hrStorageTableに入るのは、割り当て済みで固定の資源上限を持つ論理ストレージ領域である。表す量は要求主体が実際に利用できる分で、フォーマットやファイルシステム参照情報による損失を除く。標準は、これをOSが通常見る物理ストレージではなく、アプリケーションが見る論理領域だと明記した。

この定義では、容量は観測者との関係を含む。メタデータに使われるセクターは物理的に消えたわけではないが、アプリケーションには配分されない。装置全体に余裕があっても、特定の割当枠は上限に達し得る。RAMの区画、バッファープール、スワップも、要求に応じて配分されるならストレージとして現れる。

反対に、ファイルシステムのないテープやフロッピーは、存在するだけでは通常この表に入らない。OSが要求主体へ小分けして渡す資源ではないためだ。これはハードウェア目録ではなく、配分面の記録だった。

数と単位を切り離さない

各行のhrStorageAllocationUnitsは、一つの配分単位が何バイトかを示す。セクター、ブロック、バッファー、パケットを数える領域では、一単位が一バイトより大きいことが普通にある。hrStorageSizeとhrStorageUsedは、その単位の個数である。

したがって、表されるバイト数は個数と単位の積になる。サイズだけを保存し、配分単位を捨てた収集器は容量を保存していない。縮尺のない座標を保存しただけだ。単位が変わった前後を一本の系列につなげれば、整数が滑らかでも意味は連続しない。

この組み合わせは、すべての実装に一バイト単位の配分を強制しなかった。共通仕様が定めたのは解釈方法であり、実際のブロック設計は稼働するホストに残された。

装置とファイルシステムは別の証言者

物理側の情報も消されたわけではない。装置表にはホスト内の機器が並び、ディスク用の表は長期記憶装置とキロバイト単位の容量を示した。パーティションとファイルシステムにも独立した表があった。

それらの間には索引による関係があるが、完全な対応は保証されない。hrPartitionFSIndexは、パーティションにファイルシステムがない場合だけでなく、情報を取得できない場合にもゼロになり得る。hrFSStorageIndexも、ファイルシステムの使用率や容量不足を追う論理ストレージ行へ結び付けるが、情報がなければゼロである。

ゼロは「裏に装置がない」という観測結果ではない。現在の管理投影では関係を提示できないという境界だ。空欄を推測で埋めると、可視性の不足が架空の構成に変わる。

拒否回数が語らないこと

hrStorageAllocationFailuresは、空き不足のためにその領域が受け入れられなかった要求を数える。使用率の定期取得が瞬間的な逼迫を逃しても、この増分は要求が上限に触れたことを示し得る。

しかし、どのプロセスが要求したか、何バイトが拒否されたか、利用者への影響、データ損失、継続時間、復旧は記録しない。Counterには規定された初期値がなく、RFC 1514はゼロ初期化を推奨した。RFC 2790はさらに、管理局はその初期化に依存してはならないとした。一回の読み値から「起動以来の総失敗数」を作ることはできない。

論理容量と拒否イベントは別の証拠である。高い使用率は拒否を証明せず、拒否回数は失われたデータ量を証明しない。

read-writeは権限名ではない

RFC 1514は、MIBオブジェクトのアクセスレベルを、読み書きがプロトコル上意味を持つかという記述だと説明し、行政的な認可方針とは独立だとした。hrStorageSizeがread-writeでも、接続した管理者全員にサイズ変更権が生まれるわけではない。

RFC 2790は、書き込みが意味を持ち、基盤システムで実行可能な場合に限ると補足した。例は、バッファープールへ割り当てる主記憶や、仮想記憶へ割り当てるディスク領域の変更である。スキーマは操作の可能性を表す。実装が能力を持つか、誰が認可されるかは別に決まる。

RFC 1514のSecurity Considerationsは「議論しない」の一文だった。RFC 2790では、読み取り可能な構成・性能情報の機微性と、書き込みによるホスト動作変更の危険が説明された。後継標準は、測定と制御を一体化するのではなく、境界をより見える形にした。

置き換え後も残った構造

RFC 2790は2000年にRFC 1514を廃止し、定義をSMIv2へ移した。それでも、要求主体が実際に使える論理領域、固定上限、フォーマット損失の除外という中心文は残った。配分単位も、任意のファイルシステム対応も、独立した装置階層も維持された。

歴史的に重要なのは、このモデルが単なる初版の癖ではなかったことだ。異なるOSを一つの内部構造へ従わせる代わりに、遠隔利用者が意味を復元できる最小の関係を標準化した。共通なのは現実そのものではなく、現実を誤読しないための契約だった。

現代のテレメトリーでも、値には層、行ID、単位、対応関係、収集時代を同行させる必要がある。これらがあれば、物理供給、論理上限、ファイルシステム利用量、拒否イベントを別々に比較できる。捨ててしまえば、小数点以下を増やしても意味は戻らない。

出典