Кратко

  • hrStorageTable представляла логические области с фиксированными пределами и объём, реально доступный запрашивающей стороне, а не физическую ёмкость устройства.
  • hrStorageSize и hrStorageUsed считали hrStorageAllocationUnits; без размера единицы целое число не превращалось в байты.
  • Для устройств, дисков, разделов и файловых систем существовали отдельные таблицы, а нулевой индекс мог означать, что связь неизвестна.

Несовпадение не требовало пропажи

В условной консоли рядом стоят два значения. Первое относится к долговременному накопителю. Второе — к пулу, из которого приложение получает место. Второе меньше: часть носителя занята форматированием и ссылочной информацией файловой системы, часть может лежать за пределами квоты, а сам пул способен представлять swap или буферы.

Ошибка возникает не на хосте, а в экспорте, который удаляет тип и единицу строки и подписывает оба значения «диск». Разные вопросы превращаются в ложное расхождение.

Host Resources MIB создавалась для персональных компьютеров, Unix-подобных систем и иных архитектур. RFC 1514 не навязывала им единое внутреннее устройство. Концептуальные таблицы позволяли каждой машине проецировать локальные ресурсы, сохраняя понятный удалённому менеджеру контракт.

Область определялась со стороны запроса

В hrStorageTable полагалась строка для каждой уже выделенной логической области с фиксированным пределом ресурсов. Представленный объём был тем, что запрашивающая сторона действительно могла использовать, за вычетом потерь на форматирование и справочную информацию файловой системы.

Документ противопоставлял эту прикладную точку зрения физическим сущностям, которые обычно видит операционная система. Раздел, файловая система, сегмент RAM и подкачка могли быть строками одной таблицы. Их объединял способ выделения, а не одинаковый носитель.

Метаданные не исчезали физически, но не выдавались приложению как полезное место. Нижележащий диск мог иметь резерв вне конкретного лимита. И наоборот, лента или дискета без файловой системы обычно не попадала в таблицу только по факту присутствия: система не раздавала её приложениям порциями.

Число шло вместе с масштабом

hrStorageAllocationUnits задавал число байтов в одном выделяемом объекте. Для секторов, блоков, буферов или пакетов единица обычно была больше одного. hrStorageSize сообщал количество всех единиц, а hrStorageUsed — уже выделенных.

Байтовый объём получался умножением. Сохранить размер, отбросив единицу, означало оставить координату без шкалы. Если единица менялась между наблюдениями, механически соединённые значения создавали мнимый скачок, даже когда идентификатор строки выглядел прежним.

Так стандарт оставлял хосту его рабочую гранулярность. Общий слой определял интерпретацию пары, но не диктовал размер блока каждой реализации.

Физический инвентарь жил отдельно

RFC 1514 определяла таблицу устройств и специализированные таблицы процессоров, интерфейсов, принтеров и дисков. Дисковая таблица описывала долговременные накопители и ёмкость в килобайтах. Разделы и файловые системы также имели собственные идентичности.

Связь между ними была данными, а не гарантией. hrPartitionFSIndex мог равняться нулю, если в разделе нет файловой системы или сведения о ней недоступны. hrFSStorageIndex связывал локальную файловую систему с логической областью для расчёта заполнения и диагностики нехватки места; при отсутствии информации он тоже был нулевым.

Ноль не доказывал отсутствие носителя. Он честно ограничивал видимость управленческой проекции. Подставленный по догадке индекс делал схему полнее только визуально.

Отказы в выделении не были журналом потерь

hrStorageAllocationFailures считал запросы, которые область не смогла удовлетворить из-за нехватки места. Рост между двумя непрерывными пробами мог показать достижение предела, пропущенное периодическим измерением заполнения.

Но поле не называло процесс, число отклонённых байтов, пользователя, ущерб, потерю данных, длительность или восстановление. Counter не имел определённого начального значения. RFC 1514 рекомендовала ноль, а RFC 2790 добавила: станция управления не должна полагаться на такую инициализацию. Одна проба не была итогом «с момента загрузки».

Предел области, её использование и отказы были разными свидетельствами. Ни одно не создавало готовое описание инцидента.

Read-write не выдавало полномочия

RFC 1514 поясняла, что уровень доступа говорит, имеет ли чтение или запись смысл для протокола, и не зависит от административной политики авторизации. Поэтому read-write у hrStorageSize не разрешал любой станции менять размер хранения.

RFC 2790 уточнила: запись применима там, где изменение осмысленно и возможно в нижележащей системе, например при настройке памяти буферного пула или диска для виртуальной памяти. Схема выражала возможность операции, реализация — способность, а авторизация — право конкретного участника.

Первая RFC не обсуждала безопасность. Преемница предупредила о чувствительных данных конфигурации и производительности и о влиянии записываемых объектов на поведение хоста. Новая редакция не смешала наблюдение с управлением, а сделала их границу явной.

Замена RFC сохранила модель

В 2000 году RFC 2790 заменила RFC 1514 и перевела модуль на SMIv2. При этом остались логическая область с фиксированным пределом, доступный запрашивающей стороне объём, исключение служебных потерь, единица выделения, необязательная связь с файловой системой и отдельный слой устройств.

Исторический компромисс оказался устойчивым. Для совместимости хостам не требовалась одинаковая внутренняя онтология. Требовалось публиковать достаточно структуры, чтобы удалённая система не выдавала физический ресурс за логически доступную ёмкость.

Современная телеметрия нуждается в том же правиле. Вместе со значением сохраняются слой, идентичность строки, единица, связь и эпоха сбора. Если оставить только целое число, позднее уже нельзя установить, означало ли оно блоки, квоту приложения, файловую систему или устройство.

Источники