Récemment vu une question qui a suscité cette pensée. Impossible de vraiment trouver une réponse ici ou via la machine Google. Fondamentalement, je suis intéressé à savoir comment l'architecture d'E/S du noyau est en couches. Par exemple, est-ce que kjournald envoyer à pdflush ou l'inverse ? Mon hypothèse est que pdflush (étant plus générique pour les E/S de stockage de masse) se situerait à un niveau inférieur et déclencherait les commandes SCSI/ATA/tout ce qui sont nécessaires pour effectuer réellement les écritures, et kjournald gère les structures de données du système de fichiers de niveau supérieur avant l'écriture. Je pouvais aussi le voir dans l'autre sens, cependant, avec kjournald interface directe avec les structures de données du système de fichiers et pdflush se réveiller de temps en temps pour écrire des pages de pagecache sales sur l'appareil via kjournald . Il est également possible que les deux n'interagissent pas du tout pour une autre raison.
En gros : J'ai besoin d'un moyen de visualiser (graphique ou juste une explication) l'architecture de base utilisée pour répartir les E/S vers le stockage de masse dans le noyau Linux.
Réponse acceptée :
Avant de discuter des détails concernant pdflush , kjournald, and kswapd`, voyons d'abord un peu le contexte de ce dont nous parlons exactement en termes de noyau Linux.
L'architecture GNU/Linux
L'architecture de GNU/Linux peut être considérée comme 2 espaces :
- Utilisateur
- Noyau
Entre l'Espace Utilisateur et Espace noyau siège la bibliothèque GNU C (glibc ). Cela fournit l'interface d'appel système qui connecte le noyau aux applications de l'espace utilisateur.
L'espace noyau peut être subdivisé en 3 niveaux :
- Interface d'appel système
- Code noyau architectural indépendant
- Code dépendant de l'architecture
Interface d'appel système comme son nom l'indique, fournit une interface entre la glibc et le noyau. Le Code du noyau architectural indépendant est composé d'unités logiques telles que le VFS (Virtual File System) et le VMM (Virtual Memory Management). Le code dépendant de l'architecture sont les composants qui sont le code spécifique au processeur et à la plate-forme pour une architecture matérielle donnée.
Schéma de l'architecture GNU/Linux
Pour le reste de cet article, nous concentrerons notre attention sur les unités logiques VFS et VMM dans l'espace noyau.
Sous-systèmes du noyau GNU/Linux
Sous-système VFS
Avec un concept de haut niveau de la structure du noyau GNU/Linux, nous pouvons approfondir un peu plus le sous-système VFS. Ce composant est chargé de fournir l'accès aux différents périphériques de stockage de blocs qui sont finalement mappés à un système de fichiers (ext3/ext4/etc.) sur un périphérique physique (HDD/etc.).
Schéma du VFS
Ce schéma montre comment un write() du processus d'un utilisateur traverse le VFS et finit par descendre jusqu'au pilote de périphérique où il est écrit sur le support de stockage physique. C'est le premier endroit où nous rencontrons pdflush . Il s'agit d'un démon chargé de vider les blocs tampons de données et de métadonnées sales sur le support de stockage en arrière-plan. Le diagramme ne le montre pas mais il y a un autre démon, kjournald , qui se trouve à côté de pdflush , effectuant une tâche similaire en écrivant des blocs de journal modifiés sur le disque. REMARQUE : Les blocs de journal permettent aux systèmes de fichiers comme ext4 et JFS de suivre les modifications apportées au disque dans un fichier, avant que ces modifications n'aient lieu.
Les détails ci-dessus sont discutés plus loin dans cet article.
Présentation de write() étapes
Pour fournir un aperçu simple des opérations du système d'E/S, nous utiliserons un exemple où la fonction write() est appelé par une application de l'espace utilisateur.
- Un processus demande d'écrire un fichier via
write()appel système. - Le noyau met à jour le cache de page mappé au fichier.
- Un thread de noyau pdflush se charge de vider le cache de la page sur le disque.
- La couche du système de fichiers rassemble chaque tampon de bloc dans une
bio struct(reportez-vous à 1.4.3, "Couche de blocage" à la page 23) et soumet une demande d'écriture à la couche de périphérique de blocage. - La couche de périphérique de bloc reçoit les requêtes des couches supérieures et effectue une opération d'ascenseur d'E/S et place les requêtes dans la file d'attente des requêtes d'E/S.
- Un pilote de périphérique tel que SCSI ou d'autres pilotes spécifiques à un périphérique se chargera de l'opération d'écriture.
- Un micrologiciel de périphérique de disque effectue des opérations matérielles telles que la tête de recherche, la rotation et le transfert de données vers le secteur sur le plateau.
Sous-système VMM
Poursuivant notre plongée plus profonde, nous pouvons maintenant examiner le sous-système VMM. Ce composant est responsable du maintien de la cohérence entre la mémoire principale (RAM), le swap et le support de stockage physique. Le principal mécanisme de maintien de la cohérence est bdflush . Comme les pages de mémoire sont considérées comme sales, elles doivent être synchronisées avec les données qui se trouvent sur le support de stockage. bdflush coordonnera avec pdflush des démons pour synchroniser ces données avec le support de stockage.
Schéma du VMM
Échanger
Lorsque la mémoire système devient rare ou que le temporisateur d'échange du noyau expire, le kswapd démon tentera de libérer des pages. Tant que le nombre de pages libres reste supérieur à free_pages_high , kswapd ne fera rien. Cependant, si le nombre de pages gratuites tombe en dessous, alors kswapd lancera le processus de récupération de la page. Après kswapd a marqué des pages pour la relocalisation, bdflush se chargera de synchroniser toute modification en suspens sur le support de stockage, via le pdflush démons.
Références et lectures complémentaires
- Architecture conceptuelle du noyau Linux
- Le diagramme de la pile d'E/S Linux – ver. 0.1, 2012-03-06 - décrit la pile d'E/S Linux à partir du noyau 3.3
- Mise à jour des systèmes de fichiers locaux – en particulier la diapositive n° 7
- Carte interactive du noyau Linux
- Comprendre la mémoire virtuelle dans Red Hat Enterprise Linux 4
- Linux Performance and Tuning Guidelines – spécifiquement pages 19-24
- Anatomie du noyau Linux
- Le cas de la réplication à distance sensible à la sémantique