Je me demande si le stockage des informations sur les fichiers dans des inodes plutôt que directement dans le répertoire vaut la surcharge supplémentaire. Il se peut que je surestime les frais généraux ou que je néglige quelque chose d'important, mais c'est pourquoi je pose la question.
Je vois que quelque chose comme des "inodes" est nécessaire pour les liens physiques, mais au cas où la surcharge serait vraiment aussi importante que je le pense, je me demande si l'une des raisons le justifie :
- utiliser des liens physiques pour les sauvegardes est intelligent, mais l'efficacité des sauvegardes n'est pas assez importante par rapport à l'efficacité des opérations normales
- ne pas avoir de pénalité de vitesse ni de taille pour les liens physiques peut vraiment avoir de l'importance, car cet avantage ne vaut que pour quelques fichiers utiliser des liens physiques tout en accédant à tous les fichiers subit les frais généraux
- économiser de l'espace pour quelques fichiers binaires portant le même nom, comme
bunzip2etbcatest négligeable
Je ne dis pas que les inodes/hardlinks sont mauvais ou inutiles, mais cela peut-il justifier le coût de l'indirection supplémentaire (la mise en cache aide sûrement beaucoup, mais ce n'est pas une solution miracle) ?
Réponse acceptée :
Les liens durs sont hors de propos. Ils ne sont pas la raison d'avoir des inodes. Ils sont un sous-produit :en gros, toute conception raisonnable de système de fichiers de type Unix (et même NTFS est assez proche sur ce point) a des liens physiques gratuits.
L'inode est l'endroit où toutes les métadonnées d'un fichier sont stockées :son heure de modification, ses autorisations, etc. C'est également là que l'emplacement des données du fichier sur le disque est stocké. Ces données doivent être stockées quelque part.
Le stockage des données d'inode dans le répertoire entraîne sa propre surcharge. Cela rend le répertoire plus grand, de sorte que l'obtention d'une liste de répertoires est plus lente. Vous économisez une recherche pour chaque accès au fichier, mais chaque parcours de répertoire (dont plusieurs sont nécessaires pour accéder à un fichier, un par répertoire sur le chemin du fichier) coûte un peu plus cher. Plus important encore, cela rend beaucoup plus difficile le déplacement d'un fichier d'un répertoire à un autre :au lieu de déplacer uniquement un pointeur vers l'inode, vous devez déplacer toutes les métadonnées.
Les systèmes Unix vous permettent toujours de renommer ou de supprimer un fichier, même si un processus l'a ouvert. (Sur certaines variantes d'Unix, faites-le presque toujours.) C'est une propriété très importante en pratique :cela signifie qu'une application ne peut pas « pirater » un fichier. Renommer ou supprimer le fichier n'affecte pas l'application, elle peut continuer à lire et à écrire dans le fichier. Si le fichier est supprimé, les données restent jusqu'à ce qu'aucun processus n'ouvre plus le fichier. Ceci est facilité en associant le processus à l'inode. Le processus ne peut pas être associé au nom du fichier car celui-ci peut changer ou même disparaître à tout moment.
Connexe :Qu'est-ce qu'un bon outil pour visualiser les travaux de l'Agent SQL ? ?