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.