La table des inodes est-elle en memory?

Je crois comprendre que Linux localise un file sur le disque en utilisant la table inode. Le système de files Linux contient-il la table inode en memory? Serait-ce la même chose indépendamment de ext2, ext3 ou ext4?

Par hasard est-ce que quelqu'un est au courant d'une bonne reference qui décrit cela?

Cela a déjà été couvert ici: La table de files est-elle dans le système de files ou dans la memory?

Cela semble être assez approfondi. Mais c'est toujours une bonne question. Comme vous pouvez le voir, la question est en réalité plus granulaire que votre question ne le suggère.

http://140.120.7.21/LinuxKernel/LinuxKernel/node17.html c'est une explication plus technique qui semble couvrir la même question, avec la même réponse, il y a des tables inode en memory et sur le disque, de différents types, si je le lis droite. C'est à partir de 2008 mais je soupçonne qu'au less pour les filesystems ext, peu de choses ont changé, bien que je n'en sois pas certain.

L'ancienne explication du kernel est en fait assez bonne:

Un file ordinaire est juste une séquence d'octets de données stockés dans un périphérique physique sans nom associé. Les informations administratives de ce file, telles que le propriétaire, les permissions, la taille, les heures, etc., sont stockées dans la structure inode du file. Tous les inodes du système de files sont collectés set pour former une table d'inodes. Chaque système de files occupe un disque logique. A partir du bloc $ 2 ^ {nd} $ d'un disque logique, le kernel stocke la table inode du système de files dans un bloc de disque consécutif. Chaque inode, une input dans la table des inodes, est une structure de données que le système utilise pour stocker les informations suivantes sur un file:

….

Enfin, une autre structure d'inode est définie dans l'arborescence des sources Linux (include / linux / fs.h). C'est l'inode In-Core, c'est-à-dire la structure inode chargée dans la memory. Lors du chargement de cet inode In-Core, les informations relatives à l'inode du disque sont remplies dans ses champs relatifs.

Linux (et en fait tout autre Unix) n'a pas besoin d' inode pour localiser le file sur le disque, l' opération de search n'a besoin que d' inputs de directory ( dentry ), c'est-à-dire que le path est /foo/bar dans le directory "foo".

Il y a une couche de système de files croisés dans le kernel Linux qui met en cache les inputs de directory, appelées cache d'input de directory ou dcache . Cependant, il garde aussi des pointeurs vers les objects inode . Il est décrit dans kernel doc filesystems / vfs.txt :

Le VFS implémente les appels système open(2) , stat(2) , chmod(2) et similaires. L'argument de nom de path qui leur est transmis est utilisé par le VFS pour effectuer une search dans le cache d'input de directory (également appelé cache dentry ou dcache). Cela fournit un mécanisme de search très rapide pour traduire un path d'access ( nom de file ) en un dentry spécifique. Les densortinges vivent en RAM et ne sont jamais enregistrées sur disque: elles n'existent que pour la performance.

Le cache dentry est censé être une vue dans tout votre espace file. Comme la plupart des ordinateurs ne peuvent pas accueillir tous les densortinges de la RAM en même time, certains bits du cache sont manquants. Afin de résoudre votre path dans un dentry, le VFS peut avoir à recourir à la création de densortinges le long du path, puis à charger l'inode. Ceci est fait en regardant l'inode.

En général, Linux charge uniquement un inode en memory lorsque le file est ouvert. Les données peuvent persister sous forme mise à jour dans la memory pendant un certain time après la fermeture d'un file avant d'être vidée sur le disque (via la logique de caching) ou marquée désaffectée.

C'est un model d'utilisation fréquent des filesystems pour que plusieurs files soient ouverts et fermés à plusieurs resockets. Il y a de l'efficacité à ne pas relire l'inode lors des réouvertes ultérieures.

La reference faisant autorité est le code source du kernel Linux. Le directory source / documentation de l'arborescence des sources comporte souvent des détails comme ceux que vous searchz, mais peut ne pas être complètement mis à jour pour correspondre à la source.