Quelle est la différence entre «taille d'inode» et «octets par inode»


18

Les informations ci-dessous sont extraites de la page de manuel, je voudrais connaître la différence entre octets par inode et taille d'inode?

-i bytes-per-inode

Spécifiez le rapport octets / inode. mke2fs crée un inode pour chaque octet par octet d'espace sur le disque. Plus le rapport octets-par-inode est grand, moins il y aura d'inodes créés. Cette valeur ne doit généralement pas être inférieure à la taille de bloc du système de fichiers, car alors trop d'inodes seront créés. Soyez averti qu'il n'est pas possible d'augmenter le nombre d'inodes sur un système de fichiers après sa création, alors soyez prudent en décidant de la bonne valeur de ce paramètre.

-I inode-size

Spécifiez la taille de chaque inode en octets.mke2fs crée des inodes de 256 octets par défaut. Dans les noyaux après 2.6.10 et certains noyaux de fournisseurs antérieurs, il est possible d'utiliser des inodes supérieurs à 128 octets pour stocker des attributs étendus afin d'améliorer les performances. La valeur de la taille de l'inode doit être une puissance de 2 supérieure ou égale à 128. -taille, plus la table d'inodes consommera d'espace, ce qui réduit l'espace utilisable dans le système de fichiers et peut également avoir un impact négatif sur les performances. Il n'est pas possible de modifier cette valeur après la création du système de fichiers.

Réponses:


13

Eh bien, d'abord, qu'est-ce qu'un inode? Dans le monde Unix, un inode est une sorte d'entrée de fichier. Un nom de fichier dans un répertoire n'est qu'une étiquette (un lien!) Vers un inode. Un inode peut être référencé à plusieurs endroits (liens durs!).

-i octets-par-inode (alias inode_ratio)

Pour une raison inconnue, ce paramètre est parfois documenté en octets par inode et parfois en inode_ratio . Selon la documentation, il s'agit du rapport octets / inode . La plupart des humains auront une meilleure compréhension lorsqu'ils sont déclarés soit (excusez mon anglais):

  • 1 inode pour chaque X octets de stockage (où X est octets par inode).
  • la taille de fichier moyenne la plus basse que vous pouvez adapter.

La formule (tirée du mke2fs code source ):

inode_count = (blocks_count * blocksize) / inode_ratio

Ou même simplifié (en supposant que la "taille de la partition" est à peu près équivalente à blocks_count * blocksize, je n'ai pas vérifié l'allocation):

inode_count = (partition_size_in_bytes) / inode_ratio

Remarque 1: même si vous fournissez un nombre fixe d'i-noeuds au moment de la création de FS ( mkfs -N ...), la valeur est convertie en un rapport, de sorte que vous pouvez ajuster plus d'inode lorsque vous augmentez la taille du système de fichiers.

Remarque 2: Si vous ajustez ce rapport, assurez-vous d'allouer beaucoup plus d'inode que ce que vous prévoyez d'utiliser ... vous ne voulez vraiment pas reformater votre système de fichiers.

-Je taille inode

Il s'agit du nombre d'octets que le système de fichiers allouera / réserve pour chaque inode que le système de fichiers peut avoir. L'espace est utilisé pour stocker les attributs de l'inode (lire Intro to Inodes ). Dans Ext3, la taille par défaut était 128. Dans Ext4, la taille par défaut est 256 (pour stocker extra_isizeet fournir de l'espace pour les attributs étendus en ligne). lire Linux: Pourquoi changer la taille de l'inode?

Remarque: X octets d'espace disque sont alloués pour chaque inode alloué, qu'il soit libre ou utilisé, où X = taille d'inode.


5

bytes-per-inode détermine le nombre d'inodes créés pour ce système de fichiers; inode-size détermine la taille de chacun de ces inodes.

Vous avez besoin de beaucoup d'inodes si vous avez l'intention de mettre beaucoup de petits fichiers (& / ou beaucoup de répertoires) sur le système de fichiers.

AFAIK, vous n'avez vraiment besoin que d'inodes plus grands que la taille par défaut de 256 octets si vous souhaitez stocker des attributs étendus pour vos fichiers. psusi dit dans les commentaires que ce n'est pas correct.


4
En fait, les attributs étendus sont stockés dans leur propre bloc plutôt que dans l'inode, vous n'avez donc pas besoin d'un inode plus grand pour eux. Il y avait quelques correctifs flottant sur les listes de diffusion assez récemment pour enfin ajouter la possibilité de stocker des attributs étendus dans l'inode s'ils sont assez petits pour s'adapter, mais s'ils ont encore atteint la ligne principale, cela aurait été très récemment.
psusi

1

Schéma du système de fichiers extrêmement grossier:

|_|__inodes__|_______________________DATA_________________________________|
  • inode-ratio / bytes-per-inode = quantité d'inodes pour la zone DATA
  • inode-size = taille de chaque inode dans la zone des inodes

0

J'ai vraiment aimé la réponse de sjas, elle donne l'essence de la différence.

C'est juste ma propre expansion (car je ne peux pas commenter ou voter, juste en commençant par cet échange de pile) et je voulais une réponse pour moi-même énoncée de manière équilibrée en termes non techniques compréhensibles pour l'utilisateur qui doit prendre la décision pendant le volume de données configuration mais pas nécessairement connaître tous les détails de la mise en œuvre.

Personas / Objects: - volume (s) de données dans les périphériques de stockage - fichiers dans le (s) volume (s) - périphériques de stockage, ils sont formatés et fournissent des blocs d'octets et leurs adresses - emplacements des fichiers dans le stockage

Actions: créer / supprimer / renommer des fichiers et des dossiers par le système d'exploitation dans le stockage, lire / écrire / déplacer des fichiers, modifier les autorisations, etc.

Le fichier de taille N octets doit être créé en "morceaux" (blocs). Bien que théoriquement, on puisse penser que les fichiers pourraient être gérés comme des séquences d'octets uniques (ils le peuvent logiquement), tout ce dont nous aurions besoin pour gérer les fichiers dans l'espace serait un index désigné indiquant certaines propriétés de fichier (nom, etc.) et où chaque fichier commence dans le stockage. Cependant, en raison de la façon dont le matériel est conçu avec les "bus" et les "blocs" et des considérations de performances, ces "morceaux" sont de taille particulière, et un multiple de la taille de bloc du support (par exemple 512 octets, 4096 octets) et sont géré par la couche d'inodes qui indique à la couche suivante l'emplacement des fichiers et la façon dont les morceaux sont enchaînés lorsqu'ils doivent être trouvés, chargés en mémoire, etc.

Si l'on avait un gros rouleau de papier (volume) et devait concevoir un stockage d'informations pour des documents constitués de pages (de caractères ou de bits d'informations) pour stocker des documents de plusieurs pages, il fallait un index (pour trouver des documents), un espace de stockage pour les pages (avec quelques positions simples de pages). Dans le mécanisme de classement Unix (inodes) et découpage réel en pages. taille-inode est la taille d'entrée d'index (plus ou moins) octets-par-inode est la taille de la page

Effets de la modification des deux paramètres en question:

changin inode-size - généralement, il n'est pas nécessaire de changer, respectez la valeur par défaut (selon le lien publié dans la réponse précédente à une discussion)

bytes-per-inode - affecte le nombre maximal de fichiers que l'on peut éventuellement créer dans le volume (éventuellement les performances et le "gaspillage" d'octets inutilisés)

Revenons à l'analogie du rouleau de papier: imaginez devoir écrire et stocker un document de taille particulière (un fichier) dans un tel système (ou de nombreux documents de différentes tailles) - si la taille de la page, qui est définie pendant le "système d'écriture et de stockage" "définition et non flexible, est très le même document peut nécessiter de nombreuses pages, si la taille de page" système "est très grande et les tailles de document petites alors beaucoup de papier pourrait potentiellement être gaspillé en ayant des blancs et en insérant de petits fichiers sur une seule page. Si la taille de la page est grande - il y a moins de pages qui doivent être utilisées pour le document mais il pourrait y avoir beaucoup "d'espace vide gaspillé" dans la dernière page utilisée. Tout dépend donc ... de la taille des fichiers qui seront utilisés et de leur nombre. L'autre considération est la rapidité de trouver et d'apporter le document de nombreuses pages.

J'espère que cela a du sens (c'est le cas pour moi) et veuillez commenter si j'ai sérieusement abusé d'une partie de la conception ext ou des options mkfs.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.