Bonjour à tous, nous partageons avec vous la deuxième partie de la publication « Systèmes de fichiers virtuels sous Linux : pourquoi sont-ils nécessaires et comment fonctionnent-ils ? Vous pouvez lire la première partie . Rappelons que cette série de publications est programmée pour coïncider avec le lancement d'une nouvelle filière sur le parcours , qui commence très bientôt.
Comment surveiller VFS à l'aide des outils eBPF et bcc
Le moyen le plus simple de comprendre comment le noyau fonctionne sur les fichiers sysfs est de le voir en pratique, et le moyen le plus simple de regarder ARM64 est d'utiliser eBPF. eBPF (abréviation de Berkeley Packet Filter) consiste en une machine virtuelle exécutée dans , que les utilisateurs privilégiés peuvent demander (query) à partir de la ligne de commande. Les sources du noyau indiquent au lecteur ce que le noyau peut faire ; l'exécution des outils eBPF sur un système chargé montre ce que fait réellement le noyau.
Heureusement, commencer à utiliser eBPF est assez simple grâce à des outils , qui sont disponibles sous forme de packages auprès de la distribution générale et documenté en détail . Outils bcc sont des scripts Python avec de petites insertions de code C, ce qui signifie que toute personne familiarisée avec les deux langages peut facilement les modifier. DANS bcc/tools Il existe 80 scripts Python, ce qui signifie que le développeur ou l'administrateur système sera très probablement en mesure de choisir quelque chose d'approprié pour résoudre le problème.
Pour avoir au moins une idée superficielle du travail effectué par les VFS sur un système en cours d'exécution, essayez vfscount ou vfsstat. Cela montrera, disons, que des dizaines d'appels vfs_open() et « ses amis » se produisent littéralement à chaque seconde.
vfsstat.pyest un script Python avec des insertions de code C qui compte simplement les appels de fonction VFS.
Donnons un exemple plus trivial et voyons ce qui se passe lorsque nous insérons une clé USB dans un ordinateur et que le système la détecte.
En utilisant eBPF, vous pouvez voir ce qui se passe dans
/syslorsqu'une clé USB est insérée. Un exemple simple et complexe est présenté ici.
Dans l'exemple présenté ci-dessus, bcc инструмент imprime un message lorsque la commande est exécutée sysfs_create_files(). On voit ça sysfs_create_files() a été lancé en utilisant kworker stream en réponse au fait que le lecteur flash a été inséré, mais quel fichier a été créé ? Le deuxième exemple montre la puissance de l’eBPF. Ici trace.py Imprime une trace du noyau (option -K) et le nom du fichier créé sysfs_create_files(). L'insertion d'une seule instruction est du code C qui inclut une chaîne de format facilement reconnaissable fournie par le script Python qui exécute LLVM. compilateur juste à temps. Il compile cette ligne et l'exécute dans une machine virtuelle à l'intérieur du noyau. Signature complète des fonctions sysfs_create_files () doit être reproduit dans la deuxième commande pour que la chaîne de format puisse faire référence à l'un des paramètres. Les erreurs dans ce morceau de code C entraînent des erreurs reconnaissables de la part du compilateur C. Par exemple, si le paramètre -l est omis, vous verrez « Échec de la compilation du texte BPF ». Les développeurs familiers avec C et Python trouveront les outils bcc facile à étendre et à modifier.
Lorsque la clé USB est insérée, la trace du noyau montrera que le PID 7711 est un thread kworkerqui a créé le fichier «events» в sysfs. En conséquence, l'appel de sysfs_remove_files() montrera que la suppression du lecteur a entraîné la suppression du fichier events, ce qui correspond au concept général de comptage de références. En même temps, visionner sysfs_create_link () avec eBPF lors de l'insertion de la clé USB, cela indiquera qu'au moins 48 liens symboliques ont été créés.
Alors à quoi sert le fichier d'événements ? Usage Pour la recherche , montre ce que cela provoque disk_add_events (), et soit "media_change"Ou "eject_request" peut être enregistré dans un fichier d’événement. Ici, la couche de blocs du noyau informe l'espace utilisateur qu'un "disque" est apparu et éjecté. Notez à quel point cette méthode de recherche est informative en insérant une clé USB, plutôt qu'en essayant de comprendre comment les choses fonctionnent uniquement à partir de la source.
Les systèmes de fichiers racine en lecture seule activent les périphériques intégrés
Bien entendu, personne n’éteint le serveur ou son ordinateur en débranchant la fiche de la prise. Mais pourquoi? En effet, les systèmes de fichiers montés sur les périphériques de stockage physiques peuvent avoir des écritures en retard et les structures de données qui enregistrent leur état peuvent ne pas être synchronisées avec les écritures sur le stockage. Lorsque cela se produit, les propriétaires du système doivent attendre le prochain démarrage pour lancer l'utilitaire. fsck filesystem-recovery et, dans le pire des cas, perdre des données.
Cependant, nous savons tous que de nombreux appareils IoT, ainsi que des routeurs, des thermostats et des voitures, fonctionnent désormais sous Linux. Beaucoup de ces appareils ont peu ou pas d’interface utilisateur, et il n’existe aucun moyen de les éteindre « proprement ». Imaginez démarrer une voiture avec une batterie à plat lorsque l'alimentation de l'unité de commande est coupée. sauter constamment de haut en bas. Comment se fait-il que le système démarre sans attendre longtemps fsckquand le moteur démarre-t-il enfin ? Et la réponse est simple. Les appareils embarqués s'appuient sur le système de fichiers racine (abrégé ro-rootfs (système de fichiers racine en lecture seule)).
ro-rootfs offrent de nombreux avantages moins évidents que l’authenticité. L'un des avantages est que les logiciels malveillants ne peuvent pas écrire sur /usr ou /lib, si aucun processus Linux ne peut y écrire. Une autre raison est qu'un système de fichiers largement immuable est essentiel pour la prise en charge sur le terrain des appareils distants, puisque le personnel de support s'appuie sur des systèmes locaux qui sont nominalement identiques aux systèmes sur le terrain. L'avantage peut-être le plus important (mais aussi le plus insidieux) est que ro-rootfs oblige les développeurs à décider quels objets système seront immuables au stade de la conception du système. Travailler avec ro-rootfs peut être délicat et pénible, car les variables const le sont souvent dans les langages de programmation, mais leurs avantages justifient facilement la surcharge supplémentaire.
création rootfs La lecture seule nécessite des efforts supplémentaires de la part des développeurs embarqués, et c'est là que VFS entre en scène. Linux exige que les fichiers soient dans /var étaient accessibles en écriture, et en outre, de nombreuses applications populaires exécutant des systèmes embarqués tenteront de créer une configuration dot-files в $HOME. Une solution pour les fichiers de configuration dans le répertoire personnel consiste généralement à les pré-générer et à les intégrer dans rootfs. Pour /var Une approche possible consiste à le monter sur une partition inscriptible distincte, tandis que / monté en lecture seule. Une autre alternative populaire consiste à utiliser des supports de liaison ou de superposition.
Supports connectables et empilables, leur utilisation par des conteneurs
Exécution de la commande man mount est le meilleur moyen d'en savoir plus sur les montages pouvant être liés et superposés, qui donnent aux développeurs et aux administrateurs système la possibilité de créer un système de fichiers dans un chemin, puis de l'exposer aux applications dans un autre. Pour les systèmes embarqués, cela signifie la possibilité de stocker des fichiers dans /var sur un lecteur flash en lecture seule, mais un chemin de montage superposé ou pouvant être lié à partir de tmpfs в /var lors du chargement, cela permettra aux applications d'y écrire des notes (scrawl). La prochaine fois que vous activerez les modifications apportées à /var sera perdu. Un support superposé crée une union entre tmpfs et le système de fichiers sous-jacent et vous permet d'apporter des modifications apparentes aux fichiers existants dans ro-tootf alors qu'un support pouvant être lié peut en rendre de nouveaux vides tmpfs dossiers visibles en écriture dans ro-rootfs façons. Alors que overlayfs c'est la bonne (proper) type de système de fichiers, le montage pouvant être lié est implémenté dans .
Sur la base de la description de la superposition et du support connectable, personne n'est surpris que ils sont activement utilisés. Voyons ce qui se passe lorsque nous utilisons pour exécuter le conteneur à l'aide de l'outil mountsnoop à partir de bcc.
Défi system-nspawn démarre le conteneur pendant l'exécution mountsnoop.py.
Voyons ce qui se passe:
Запуск mountsnoop pendant que le conteneur est en train de "démarrer", cela montre que le temps d'exécution du conteneur dépend fortement du montage lié (seul le début de la longue sortie est affiché).
il est systemd-nspawn fournit les fichiers sélectionnés dans procfs и sysfs hôte vers le conteneur comme chemin d'accès rootfs... outre MS_BIND indicateur qui configure le montage de liaison, d'autres indicateurs sur le montage définissent la relation entre les modifications apportées aux espaces de noms de l'hôte et du conteneur. Par exemple, une monture liée peut ignorer les modifications apportées à /proc и /sys dans le conteneur, ou cachez-les en fonction de l'appel.
Conclusion
Comprendre le fonctionnement interne de Linux peut sembler une tâche impossible, puisque le noyau lui-même contient une énorme quantité de code, laissant de côté les applications de l'espace utilisateur Linux et les interfaces d'appel système dans les bibliothèques C telles que glibc. Une façon de progresser consiste à lire le code source d'un sous-système du noyau, en mettant l'accent sur la compréhension des appels système et des en-têtes de l'espace utilisateur, ainsi que des principales interfaces internes du noyau, telles que les tables. file_operations. Les opérations sur les fichiers respectent le principe « tout est un fichier », ce qui les rend particulièrement agréables à gérer. Fichiers sources du noyau C dans le répertoire de niveau supérieur fs/ présentent une implémentation de systèmes de fichiers virtuels, qui constituent une couche wrapper qui offre une compatibilité large et relativement simple entre les systèmes de fichiers et les périphériques de stockage courants. La liaison et le montage par superposition via les espaces de noms Linux sont la magie de VFS qui rend possible la création de conteneurs en lecture seule et de systèmes de fichiers racine. Combiné à un examen du code source, de l'outil principal eBPF et de son interface bcc
rendant l'exploration de base plus facile que jamais.
Amis, écrivez, cet article vous a-t-il été utile ? Peut-être avez-vous des commentaires ou des remarques ? Et ceux qui sont intéressés par le cours Administrateur Linux sont invités à , qui aura lieu le 18 avril.
Source: habr.com