Résumé

  • La hrStorageTable de la RFC 1514 décrivait des zones logiques à limite fixe, selon la quantité réellement utilisable par l’entité qui demandait du stockage.
  • hrStorageSize et hrStorageUsed comptaient des hrStorageAllocationUnits ; sans cette unité, la valeur brute n’était pas un nombre d’octets.
  • Les dispositifs, disques, partitions et systèmes de fichiers conservaient leurs propres tables, et un indice nul pouvait signaler une relation indisponible plutôt qu’une absence physique.

L’erreur venait du nom de la colonne

Prenons une scène construite. Une console reçoit la capacité d’un disque à long terme et, quelques lignes plus loin, la taille d’une réserve accessible à une application. La seconde est plus petite. Une partie du support sert au formatage et aux références du système de fichiers ; une autre peut rester hors de la limite imposée à cette réserve. Les deux mesures sont exactes.

La contradiction n’apparaît que lorsqu’un export les renomme toutes deux « taille du disque ». Le nom commun efface l’observateur, la relation d’allocation et l’unité. L’écart devient alors, à tort, une perte à expliquer.

La Host Resources MIB devait rendre comparables des ordinateurs personnels, des systèmes de type Unix et d’autres architectures. La RFC 1514 n’a pas choisi d’imposer leur organisation interne. Elle a défini des tables conceptuelles afin qu’une station distante sache quelle réalité chaque objet projetait.

Une réserve définie par celui qui demande

La description de hrStorageTable pose une règle d’admission. Chaque zone logique déjà allouée et soumise à une limite fixe devait recevoir une entrée. La quantité représentée était celle que l’entité demandeuse pouvait réellement utiliser, après exclusion des pertes dues au formatage ou aux informations de référence du système de fichiers.

Le texte opposait expressément cette vue, proche de celle d’une application, aux entités physiques qu’un système d’exploitation voit d’ordinaire. Une partition, un système de fichiers, une zone de mémoire ou l’espace d’échange pouvaient donc figurer dans la table. Ils partageaient un contrat d’allocation, pas une matière identique.

Inversement, une bande ou une disquette sans système de fichiers n'y entrait généralement pas du seul fait de son existence. Si le système ne la découpait pas en unités attribuées aux applications, elle ne répondait pas à la question posée par cette table. La présence physique et la disponibilité logique restaient deux affirmations.

Le multiplicateur silencieux

Chaque ligne portait hrStorageAllocationUnits, la taille en octets d’un objet alloué depuis la réserve. Pour des secteurs, blocs, tampons ou paquets, cette valeur pouvait être supérieure à un. hrStorageSize indiquait le nombre total d’unités et hrStorageUsed le nombre d’unités allouées.

Une capacité en octets exige donc le produit du nombre et de l’unité. Conserver la taille brute tout en abandonnant le multiplicateur revient à archiver une mesure sans échelle. Relier deux observations dont l’unité a changé fabrique également une fausse variation, même si l’identifiant de ligne semble stable.

Ce choix permettait aux implémentations de garder leurs tailles de bloc locales. La norme commune définissait juste assez de structure pour qu’un autre système puisse interpréter le résultat. Elle n'élevait pas une convention locale en loi universelle.

Les autres tables racontaient d’autres vérités

La RFC 1514 disposait aussi d’une table des dispositifs, complétée par des tables pour processeurs, interfaces, imprimantes et disques. La table des disques décrivait les dispositifs de stockage de longue durée et exprimait leur capacité en kilooctets. Partitions et systèmes de fichiers possédaient encore leurs propres identités.

Les liens n’étaient pas garantis complets. hrPartitionFSIndex pouvait valoir zéro si une partition ne contenait pas de système de fichiers, mais aussi si l’information manquait. hrFSStorageIndex reliait un système de fichiers local à l’entrée logique utile pour suivre son taux d’utilisation et diagnostiquer le manque de place ; lui aussi valait zéro en l’absence d’information disponible.

Un zéro ne démontrait donc pas l’absence de support sous-jacent. Il conservait honnêtement une ignorance dans la projection de gestion. Le remplacer par une relation supposée aurait transformé une lacune de visibilité en topologie fictive.

Un refus n’était pas une quantité perdue

hrStorageAllocationFailures comptait les demandes que la réserve n’avait pu honorer faute d’espace. Une augmentation pouvait révéler qu’une limite avait été atteinte entre deux échantillons d’utilisation. Elle ne donnait ni le processus demandeur, ni le volume refusé, ni l’impact utilisateur, ni la durée, ni la récupération.

Comme tout Counter de ce cadre, l’objet n’avait pas de valeur initiale définie, bien que la RFC 1514 recommandât zéro. La RFC 2790 a conservé cette recommandation tout en interdisant aux stations de gestion d'en dépendre. Une lecture isolée ne constituait donc pas un total « depuis le démarrage ». Il fallait une époque continue et des différences entre observations.

La limite logique et les refus d’allocation étaient deux surfaces de preuve. Ni l’une ni l’autre ne décrivait à elle seule un incident ou un résultat métier.

La possibilité d’écrire ne désignait pas le décideur

Dans son rappel du cadre SNMP, la RFC 1514 précisait que le niveau d’accès indiquait si lire ou écrire avait un sens protocolaire et restait indépendant de la politique d’autorisation administrative. Le statut read-write de hrStorageSize n’accordait pas à toute station la faculté de redimensionner n’importe quel disque.

La RFC 2790 a explicité le périmètre : l’écriture s’appliquait lorsque l’opération avait un sens et que le système sous-jacent la permettait, par exemple pour modifier la mémoire d’un pool de tampons ou l’espace disque réservé à la mémoire virtuelle. Le schéma exprimait une opération possible ; l’implémentation déterminait la capacité ; l’autorisation déterminait l’acteur.

La première RFC se contentait d’indiquer que les questions de sécurité n’étaient pas discutées. Sa remplaçante a décrit la sensibilité des informations de configuration et de performance, ainsi que le danger des objets modifiables. Cette évolution a renforcé la frontière entre observation, possibilité technique et pouvoir légitime.

La RFC 2790 n’a pas fusionné les couches

En 2000, la RFC 2790 a remplacé la RFC 1514 et porté le module vers SMIv2. Elle a pourtant conservé la définition d’une zone logique à limite fixe, utilisable par l’entité demandeuse et nette des pertes de formatage. Elle a gardé les unités d’allocation, les associations éventuellement inconnues et l’inventaire physique séparé.

Cette continuité révèle le vrai compromis historique. L’interopérabilité ne demandait pas une ontologie interne identique sur tous les hôtes. Elle demandait que le type, l’unité et la relation accompagnent la valeur publiée. La couche commune devait être assez précise pour empêcher une mauvaise lecture, et assez étroite pour laisser chaque machine organiser ses ressources.

La même discipline vaut pour la télémétrie actuelle. Une valeur doit voyager avec la couche représentée, l’identité de ligne, l’unité, les associations et l’époque de collecte. Si ces éléments sont perdus, aucun affichage ultérieur ne peut déterminer si l’ancien entier désignait des blocs, un quota applicatif, un système de fichiers ou un dispositif.

Sources