La magie des filesystems : 1- Tour d'horizon

1. Le filesystem au début de son histoire

Historiquement, un système de fichiers n'était guère plus qu'un simple « gestionnaire de disques ».

Ce module de l'OS a été conçu comme un passage obligé pour tous les processus qui souhaitent écrire ou lire sur le disque. Avec cette position centrale, on pouvait assurer une cohérence entre les zones allouées pour ces différents processus.

On a alors appelé ces « zones du disque » des « fichiers » et donc, ce module est devenu un « système de fichiers », au sens classique du terme.

Pour repérer les fichiers sur le disque, on a aussi introduit les répertoires, ce qui a permis d'obtenir une vision hiérarchique (arborescente) des données.

2. Les filesystems dits « virtuels »

Cette approche ayant eu un succès certain, on a commencé à étendre l'utilisation des filesystems bien au-delà de cette approche historique. À tel point qu'on dit, depuis un certain temps déjà, que « tout est fichier ».

Ce qu'on a gardé de l'approche classique du système de fichiers, c'est la représentation arborescente. Par contre, pourquoi ne pas représenter autre chose que des zones allouées dans un espace de stockage ?

Par exemple, pourquoi ne pas utiliser un filesystem pour représenter les informations sur les processus en cours d'exécution, avec un répertoire par PID ? C'est ce que fait (entre autres fonctionnalités) le filesystem monté sur /proc.

Et les périphériques connectés ? C'est ce qu'on monte sur /dev.

Et pourquoi ne pas revenir à la notion historique des filesystems et donc, faire de la gestion d'espace, mais en mémoire plutôt que sur disque ? Pour des fichiers temporaires, cela pourrait grandement accélérer les choses ! Eh bien c'est ce que fait tmpfs.

Je vais m'arrêter là, mais il est clair que les exemples ne manquent pas.

Ce qu'il faut bien voir, c'est qu'avec chaque nouveau filesystem de ce genre, on étend d'avantage le concept du « tout est fichier ». Et j'espère bien qu'on continuera à l'étendre. Par exemple, sous Linux, les interfaces réseau ne sont pas (encore) vues comme un fichier. Cela serait pourtant utile pour envoyer ou lire des paquets en mode « raw », en utilisant simplement nos outils UNIX classiques¹... Cela dit, rien n'empêche² de coder un filesystem adéquat, qui remplisse cette fonction et d'autres, et qu'on pourrait monter sur /net...

3. FUSE : codage en espace utilisateur

En réalité, cette explosion de filesystems en tous genres n'en était qu'à ses débuts. Il était clair que le concept de filesystem pouvait être utilisé à des fins très diverses et la demande était bien là. Mais l'offre était finalement limitée, car tout le monde n'a pas l'habitude de la programmation noyau.

Jetons un œil sur l'architecture sur laquelle reposent les filesystems.

Le cas le plus simple est sans doute celui d'un filesystem comme procfs.

Sur cette figure, la commande cat /proc/1121/exe est exécutée. Sous Linux, le processus d'analyse des chemins est effectué par le module VFS (Virtual File System) du noyau. Celui-ci analyse donc le chemin /proc/1121/exe à partir de la racine jusqu'au dernier élément. Comme un filesystem de type procfs est monté sur /proc, il transmet la requête de lecture au module dédié à la gestion de ce filesystem (module proc indiqué sur la figure), qui renverra le résultat.

Le cas de ext4 n'est pas vraiment plus complexe.

Cette fois, c'est la commande cat /etc/hosts qu'on exécute. À nouveau, le chemin est analysé par VFS. Comme un filesystem de type ext4 est monté sur /, il transmet la requête de lecture au module dédié à la gestion de ce filesystem (module ext4 indiqué sur la figure). Ce module fera alors une lecture sur le disque (sauf si les données sont en cache) et pourra retourner le résultat.

Avec l'apparition du module FUSE dans le noyau, une nouvelle architecture est apparue (voir figure suivante) et avec elle, une nouvelle méthode pour implémenter les systèmes de fichiers.

Cette fois, la commande que l'on a exécutée est : cat /tmp/mountpoint/stock. On considère ici qu'un filesystem « charpentefs », utilisé pour gérer les stocks d'un charpentier, est monté sur /tmp/mountpoint. Charpentefs étant un filesystem basé sur FUSE, c'est vers ce module que la requête sera redirigée. Ce module fait alors office de passerelle vers le programme chargé de la gestion de ce filesystem. Ce qui est fondamental ici, c'est que ce programme tourne en espace utilisateur et non dans le noyau...³

Développer un filesystem en utilisant FUSE présente ainsi un avantage important : le programmeur n'a pas à écrire du code noyau. Et, s'agissant de code utilisateur, les risques pour la stabilité du système sont moindres, donc le développement peut se faire sans trop de précautions.

En revanche, cette indirection supplémentaire provoque évidemment une baisse de performances. Linus Torvalds a déclaré un jour à ce sujet : « People who think that userspace filesystems are realistic for anything but toys are just misguided »⁴. Les avis tranchés de Linus sont bien connus... ;) A mon avis, FUSE est parfait pour un prototype ou même, si on n'a pas besoin de hautes performances, pour un filesystem finalisé. Et même en matière de performances, il faut faire la part des choses. Par exemple, si les données qu'affiche votre filesystem sont stockées sur une autre machine du réseau, alors le temps d'accès à ces données aura sans doute d'avantage d'impact que l'architecture (FUSE ou noyau) que vous choisirez.

4. Les live CD : une arborescence de filesystems

Comme nous allons le voir dans cette partie, les live CD constituent un cas d'utilisation relativement avancée des filesystems.

4.1 Les premiers live CD : ramdisk + filesystem

Le côté magique des filesystems me fascine depuis plusieurs années. Vers 2004, j'ai étudié le fonctionnement de la distribution Damn Small Linux et j'ai fini par la modifier pour les besoins de l'entreprise où je travaillais. Ce qui m'intéressait le plus, c'était l'aspect « live ». Comment peut-on, à partir d'un support en lecture seule (CD), booter un système qui nous autorise à créer ou modifier des fichiers ??

En réalité, dans Damn Small Linux, on ne pouvait pas modifier les fichiers, mais on pouvait déjà en créer. En effet, /home/<user> était le point de montage d'un filesystem créé dans un « ramdisk » (espace réservé en mémoire vive). Les fichiers créés dans ce répertoire étaient ainsi stockés en mémoire. Mais cette technique était relativement limitée : il était impossible d'installer (ou de mettre à jour) un programme, sauf en l'installant dans ce répertoire, tout le reste de l'arborescence étant en lecture seule.

En fait, il restait bien un moyen pour rendre des fichiers existants modifiables : au démarrage de l'OS, on les lit sur le CD et on les copie sur le ramdisk. Mais ce n'est pas très optimal : avec une quantité de mémoire réduite, on ne peut pas tous les copier de cette manière. Et cette copie prend du temps au démarrage (car lire le CD prend du temps).

4.2 tmpfs : stockage de fichiers en RAM

Aujourd'hui, plutôt que d'empiler un filesystem (de son choix, par exemple ext2...) dans un ramdisk, on utilise plutôt tmpfs. Il s'agit d'un filesystem qui stocke les fichiers en mémoire et qui permet donc d'obtenir un résultat comparable en une seule opération. Par exemple :

À partir de là, ce qu'on fera dans /tmp sera fait en mémoire, ce qui permet d'obtenir une réactivité qu'on n'aura jamais avec un disque (même SSD). (Bien sûr, il faut garder à l'esprit qu'on est limité par la taille de nos barrettes et que, si votre fils appuie sur l'interrupteur de la multiprise, vous perdez votre travail).

Dans cet exemple, on voit aussi que le prototype de la commande mount nous oblige à spécifier un device. Il s'agit d'un héritage de l'époque où les filesystems étaient utilisés uniquement pour les disques. Cela ne s'applique pas à notre cas, j'ai donc mis no_device, mais on peut en réalité mettre n'importe quelle chaîne.⁵

4.3 Les systèmes de fichiers « union »

Les live CD ont pris une autre dimension avec l'apparition des systèmes de fichiers « union ». Un de leurs premiers représentants fut unionfs, puis aufs (les deux ont la même syntaxe). Voici un exemple qui illustre cette notion d'« union » :

Voilà pour le petit exemple amusant. Mais ces systèmes de fichiers en « union » peuvent faire bien plus que ça...

Commençons par remonter l'union en précisant que dir2 ne doit pas être modifié :

Donc, logiquement, il n'est plus possible de supprimer file2, car il est dans l'arborescence de dir2, qui est en lecture seule...

Pas d'erreur ??

Vérifions que la suppression a vraiment été effectuée :

Apparemment oui, donc l'union file2 n'est plus visible.

Est-ce que ce fichier aurait été supprimé dans l'arborescence de dir2 malgré l'option de montage dir2=ro ??

Non, il est toujours là !

Au cas où, voyons ce qu'on a dans dir1, qui lui, pouvait être modifié...

Voilà donc toute la subtilité... Comme il n'est pas autorisé à supprimer un fichier dans l'arborescence de dir2, aufs a créé ce fichier .wh.file2⁶ dans la branche où il peut écrire, celle de dir1.

Au prochain démontage-remontage, aufs saura interpréter l'existence de ce fichier « spécial » et donc, file2 ne sera toujours pas visible dans l'arborescence du point de montage.

Revenons à nos moutons... Et imaginons maintenant les montages suivants :

S'agissant d'une union, dans /mnt/union on voit, au départ, tous les fichiers du cdrom. Si ensuite des fichiers sont créés dans ce point de montage, ils seront écrits dans la branche en lecture-écriture, celle de tmpfs, donc en mémoire. Et si on supprime un fichier, cette suppression sera gérée via la création d'un fichier .wh.<file> dans l'arborescence de tmpfs.

On a donc, en quelque sorte, créé une couche (overlay) tmpfs, permettant de rendre l'arborescence de notre cdrom modifiable à souhait !

Il ne reste plus qu'à remplir le CD avec une arborescence d'OS et, si on fait booter l'OS de cette manière, on pourra tout modifier... Voilà donc la base des distributions live CD modernes...

4.4 chroot : changeons de référentiel

Je vous raconte des trucs, mais peut-être que vous commencez à vous dire que j'ai tout imaginé depuis le début...

En effet, si je démarre une distribution live CD, disons une Ubuntu, je devrais donc m'attendre à ce que tous les chemins soient préfixés par le point de montage de l'union, non ?

Par exemple, pour lancer bash, il faudrait taper quelque chose comme /mnt/union/bin/bash... Et ce n'est pas le cas : je lance juste /bin/bash. Il y a donc une autre étape...

Cette autre étape, c'est d'indiquer à /mnt/union/bin/bash que la racine de son système de fichiers n'est pas / mais plutôt /mnt/union. C'est ce que fait la commande chroot⁷. En voici la preuve :

Au 1er appel de la commande pwd, celle-ci nous indique qu'elle est lancée dans le répertoire /mnt/union. Au 2ème appel, chroot nous permet de lui indiquer que le répertoire courant (donc /mnt/union) est la racine de son système de fichiers ; elle nous renvoie donc /.⁸

Ce qu'il faut bien comprendre, c'est que, au final, la racine du système de fichiers n'est qu'un paramètre de chaque processus...

De plus, ce paramètre est transmis aux processus fils. Donc... il suffit de faire un chroot dans le 1er processus du système (/mnt/union/sbin/init a priori) pour que tous les processus considèrent que /mnt/union est leur racine !

Voilà donc pourquoi /mnt/union n'est pas visible une fois l'OS lancé.

4.5 squashfs : ajoutons de la compression

En dehors de la gestion du périphérique en lecture seule, les distributions basées sur un live CD doivent prendre en compte l'espace réduit disponible sur un CD.

Et là, vous commencez à deviner la solution : une autre couche de filesystem !

Certains filesystems proposent en effet de compresser les données (btrfs par exemple). Le plus simple à implémenter est de compresser le contenu de chaque fichier. Certains sont également capables de compresser les métadonnées (propriétaire, groupe, permissions, etc.).

Le filesystem squashfs⁹ est capable de compresser encore plus. En effet, plutôt que de compresser chaque fichier indépendamment des autres, on peut tirer partie des corrélations entre eux. Mais ce niveau de compression est à peu près ingérable dès qu'on autorise la modification des fichiers... C'est pourquoi squashfs est un système de fichiers en lecture seule. Mais, sur un live CD, où est le problème ? Le CD est déjà en lecture seule...

Voilà donc pourquoi, quand on installe une distribution à partir d'un live CD de 700Mo, on se retrouve avec un filesystem installé qui prend dans les 2 Go ou plus...

4.6 Mise en pratique : modification d'un live CD Ubuntu

Imaginons que vous vouliez déclarer un truc à une fille qui vous a demandé de réparer son PC. Déjà, vous avez prévu de lui installer un bon vieux système GNU/Linux, histoire de la libérer de l'emprise d'une multinationale. Et vous avez prévu le plan diabolique suivant :

- Vous allez modifier l'image ISO de l'OS à l'avance, pour ajouter un fichier secret.txt sur le bureau ;

- Vous partirez aux toilettes avant que le bureau ne s'affiche pour qu'elle ait envie d'ouvrir ce fichier.

Allez, c'est parti ! (J'ai une image d'Ubuntu 12.04 (« Precise ») sous la main, mais ce serait à peu près la même chose avec les versions qui suivent...).

Voyons ce qu'on a dans cette ISO :

Ce fichier filesystem.squashfs a un nom bien explicite : c'est une image de filesystem compressée par squashfs. Il nous faut un montage de plus...

Voilà.

Pour notre modification, il y a une chose à savoir. En fait, quand on lance Ubuntu en mode live, l'utilisateur de la session live est créé dynamiquement (via une commande adduser ou un truc du genre). Si vous vous rappelez bien vos cours de système, quand on crée un utilisateur, le contenu de /etc/skel (pour skeleton) est copié dans le répertoire /home/<user> nouvellement créé. Cela permet de mettre en place un environnement minimal automatiquement pour chaque nouvel utilisateur créé. Donc, a priori, si on met notre fichier à l'emplacement /etc/skel/Desktop/secret.txt, il devrait se retrouver sur le bureau... Allons-y :

Ah mince ! Évidemment, on est en lecture seule. A la fois l'ISO et l'image squashfs d'ailleurs...

Pour effectuer notre modification, il va falloir adopter une méthode différente. Voici celle qu'on trouve sur Internet :

1) extraire le contenu de l'ISO,

2) extraire le contenu de l'image squashfs,

3) modifier les fichiers comme on veut,

4) recompresser l'image squashfs,

5) reformater l'ISO,

6) supprimer les fichiers temporaires.

Vous voyez ce que je vois ?? On traite les images de filesystem comme de vulgaires archives !! Clairement, je ne le permettrai pas. Surtout dans cet article ! ;)

En fait, pour toucher du doigt la puissance des filesystems, on adoptera plutôt cette méthode-là :

1a) monter l'ISO,

1b) monter une union « union_iso » avec un overlay pour pouvoir modifier les fichiers de l'image ISO,

2a) monter l'image squashfs,

2b) monter une union « union_filesystem » avec un overlay pour pouvoir modifier les fichiers de l'image squashfs,

3) modifier les fichiers comme on veut,

4) recompresser l'image squashfs à l'emplacement adéquat de « union_iso »,

5) reformater l'ISO,

6) démonter.

En fait, ce n'est pas vraiment plus compliqué. D'ailleurs, on a toujours 6 étapes ;) Le principe, c'est qu'on a remplacé les 2 phases d'extraction par, à chaque fois, un montage et la mise en place d'une « union » pour gérer les modifications.

Outre le plaisir d'ajouter des niveaux d'abstraction, il y a clairement 2 avantages :

- Les extractions prennent du temps alors que les montages sont quasi-instantanés ;

- Ces deux phases d'extraction demandent beaucoup d'espace disque (temporaire), plusieurs gigas a priori (vu qu'on extrait tous les fichiers et que ceux-ci ne seront plus compressés). Alors que nos « unions » vont stocker uniquement ce qu'on modifie.

Pour être honnête, si on a pas mal d'espace disque, on aurait presque pu envisager la première méthode. Mais cela reste non optimal, donc désagréable pour l'esprit. :) Et si un jour vous envisagez d'industrialiser vos modifications d'image ISO, pour, par exemple, publier et maintenir une distribution maison (dérivée d'Ubuntu), alors il faudra appliquer ces modifs dans un script. Et là, il n'y a plus qu'un seul choix raisonnable, à mon avis.

Allons-y. En fait, plus haut, on a déjà fait les étapes 1a et 2a (montage ISO et image squashfs). On enchaîne donc avec les unions :

Le montage de rw_iso et rw_filesystem en mémoire (tmpfs) est optionnel. Il faut d'ailleurs se méfier, car si on a beaucoup de modifications à faire, on peut être limité par la quantité de mémoire sur la machine. Ici, on va en particulier mettre à jour le fichier casper/filesystem.squashfs dans union_iso et ce fichier fait quasiment 700 Mo. Sur une machine limitée en mémoire, il faudrait donc éviter ce montage.

On peut maintenant revenir à la modification que l'on voulait réaliser au départ :

Et voilà.

Notez qu'à cette étape on peut entreprendre des modifications de bien plus grande envergure, comme par exemple ajouter ou supprimer des paquets. Le principe est grosso-modo le suivant :

L'astuce est ainsi d'utiliser chroot pour interagir au sein de l'arborescence du filesystem.¹⁰

Une fois les modifications effectuées, on peut maintenant reformater l'image squashfs :

Et reformater l'ISO¹¹:

La dernière étape consiste à démonter les filesystems créés jusqu'ici, du dernier créé au premier créé (c'est trivial, je ne détaille pas).

Et c'est tout bon, il ne vous reste plus qu'à tenter votre chance avec cette fille et moi à me réjouir de participer à la lutte contre le célibat...

5. Boot réseau et hébergement de filesystem

5.1 Contexte

Dans mon labo, on veut mettre en place un banc de test pour les réseaux de capteurs. Dans ce cadre, on a un ensemble de cartes Raspberry Pi qui bootent en réseau. Et sur certains points, cette problématique se rapproche... de celle des live CD¹² !

Les cartes Raspberry Pi disposent d'un lecteur de carte SD. De ce fait, en général, on installe leur OS sur la carte SD. Dans notre cas, afin de faciliter l'administration du système, nous avons préféré réduire au strict minimum le contenu de cette carte (on n'y met que le bootloader, u-Boot), et les faire booter via le réseau, en utilisant un serveur central DHCP, TFTP & NFS. Et de ce fait, nous utilisons la carte SD uniquement en lecture. Nous pouvons donc en espérer une durée de vie bien supérieure.

5.2 Création du filesystem des Raspberry Pi

Sur le serveur, nous avons donc un répertoire /nfs/debian-fs qui contient l'arborescence de l'OS utilisé par les Raspberry Pi. Ce filesystem a été créé en utilisant la commande habituelle pour initialiser une arborescence de système Debian :

Dans notre contexte, les clients NFS (les Raspberry Pi) n'ont pas la même architecture que le serveur, il faut donc bien préciser l'option --arch adéquate.

Après cette initialisation, nous devons bien évidemment adapter cette arborescence à notre problème, installer les outils nécessaires pour la gestion du banc de test, etc.

Dans ce genre de cas, vous devez commencer à connaître la technique :

Essayons :

Ah oui, évidemment... L'architecture est différente... Notre serveur sera bien incapable d'exécuter les binaires de cette arborescence (tels que /nfs/debian-fs/bin/sh ou /nfs/debian-fs/usr/bin/apt-get), s'agissant de binaires pour architecture ARM !

Eh bien en fait si, il en sera capable. Juste après ça :

Et c'est tout ? Eh bien oui. La preuve :

Voilà qui mérite une petite explication...

Pour faire tourner un binaire d'une architecture différente, il existe bien une solution : utiliser un émulateur, tel que qemu. Il est donc logique d'installer qemu. Et comme on va faire des indirections, à coups de chroot, on a choisi la version compilée en statique (sinon c'est plus compliqué à cause des chemins des librairies partagées).

Le paquet nous a ainsi installé le binaire /usr/bin/qemu-arm-static. Voilà donc de quoi émuler des binaires ARM. On peut tester avec un binaire ARM téléchargé sur Internet :

Voilà pour la vérification. Mais vous allez me dire que, pour le chroot, je n'ai pas utilisé qemu-arm-static et ça marchait quand même.

Eh bien en fait, là non plus, je ne suis plus obligé de le préciser :

Voilà qui vous en bouche un coin... On s'attendait plutôt à un « Exec format error » comme tout à l'heure, non ?

L'astuce, c'est que l'installation du paquet qemu-user-static a fait plus de choses que ce à quoi on s'attendait : elle a aussi enregistré tout un tas de nouvelles associations dans le système binfmt_misc du noyau :

Celle qui nous intéresse ici est bien évidemment qemu-arm :

Voilà donc la clé de l'énigme : grâce à cette association, quand on demande au noyau d'exécuter un fichier qui correspond aux champs magic et mask, il va lancer l'interpréteur indiqué (/usr/bin/qemu-arm-static ici) et cela de manière totalement transparente pour l'utilisateur !

Puissant ce système binfmt_misc, non ?

Revenons à nos moutons.

Nous avons donc tout ce qu'il faut pour customiser le système que vont booter nos Raspberry Pi :

L'émulation est assez transparente pour l'utilisateur, sauf concernant 2 choses :

- c'est beaucoup plus lent, évidemment. Si vous voulez recompiler le noyau linux, alors cet environnement peut paraître pratique (pas de cross-compilation à configurer car le gcc de cet environnement va générer nativement des binaires ARM...) ; mais le temps de compilation va sans doute vous décourager !

- on peut rencontrer des erreurs si qemu ne supporte pas certaines fonctionnalités. La plupart du temps, on peut ignorer ces erreurs (comme celle reportée ici), mais il peut arriver que cela soit bloquant, pour certaines tâches bas-niveau.

Dans l'ensemble cela reste très pratique et fonctionnel.

5.3 Gestion du partage NFS en lecture seule

Bon, maintenant qu'on a préparé l'OS qui doit booter par le réseau, il reste un souci à gérer. Si on autorise chaque nœud Raspberry Pi à accéder en lecture-écriture à ce partage NFS, on va sans doute avoir des soucis, avec toutes les lectures & écritures concurrentes.

Il faut donc configurer le partage NFS en lecture seule. L'ennui, c'est que la distribution Debian que l'on a installée et configurée sur ce partage NFS n'est pas adaptée pour tourner sur un système de fichiers en lecture seule.

La solution, c'est que chaque Raspberry Pi suive le fonctionnement suivant :

1) Récupération (via TFTP) et boot du noyau Linux,

2) Montage du partage NFS (via l'option adéquate du noyau) en lecture seule,

3) Montage d'une union avec un overlay tmpfs pour stocker en mémoire les fichiers créés ou modifiés,

4) Lancement de l'OS sur l'union (via chroot).

Quand je vous disais que cette problématique se rapproche de celle des live CD !

Les étapes 1 et 2 sont l'affaire du bootloader et du noyau, je ne vais pas les détailler ici. Reste à imaginer comment on va insérer l'étape 3 avant le lancement de l'OS.

En fait, une fois le noyau lancé et le système de fichiers racine monté (ici le partage NFS), le noyau démarre l'OS en exécutant le premier processus, celui qui lance tous les autres. Sauf option noyau spécifique, ce premier processus est lancé en exécutant le fichier /sbin/init.

Voilà donc comment on peut insérer cette étape 3 :

Et voilà. Le noyau va maintenant appeler notre init customisé à la place de l'ancien. Ce nouvel init devra ainsi créer l'union puis lancer /sbin/init.orig sur cette union.

Pour l'union, le script va avoir besoin de 2 points de montage. Le filesystem NFS sera en lecture seule, donc on ne pourra pas les créer dans le script ! Donc on le fait maintenant :

Et voilà ce script init customisé¹³ :

La fonction mount_and_run_startup_init() ne doit pas trop vous surprendre...

Le if à la fin est moins évident. En fait, historiquement, les scripts init doivent être capables de fournir 2 fonctionnalités :

F1) Initialiser l'OS, donc faire office de 1er processus et lancer tous les autres ;

F2) Fournir une interface à ce processus d'initialisation.

Vous est-il déjà arrivé de taper la commande init 0 pour arrêter l'OS ou init 6 pour rebooter ? Cela correspond à F2. Dans ce cas, la commande init doit envoyer un message au 1er processus (celui qui a été créé par F1...), pour lui demander de passer dans le runlevel indiqué.

La méthode pour déterminer la fonctionnalité à remplir (F1 ou F2) consiste à vérifier si on est le 1er processus ou non. La variable spéciale $$ renvoie le PID du processus en cours d'exécution... Ce qui explique ce if à la fin du script. Si on est effectivement le 1er processus, on lance l'OS en appelant mount_and_run_startup_init(). Sinon, on délègue directement la requête à /sbin/init.orig, en lui passant le même argument que celui qu'on a reçu ; /sbin/init.orig n'aura pas non plus un PID égal à 1, donc il saura qu'il doit remplir la fonctionnalité F2.

Il y a quand même une subtilité dans mount_and_run_startup_init(). Avez-vous remarqué le exec avant le chroot ? Sans lui, la commande chroot . sbin/init.orig serait lancée dans un nouveau processus, donc avec un PID différent de 1. Donc init.orig croirait qu'il doit remplir la fonctionnalité F2 au lieu de F1 et c'est le kernel panic assuré. Au contraire, en préfixant avec exec, le processus en cours d'exécution est « remplacé » par la commande indiquée et de ce fait le PID (égal à 1 dans ce cas) est conservé.

Une fois ce script d'init mis en place, nos Raspberry Pi peuvent cohabiter sur le même partage NFS, en stockant les écritures en mémoire... Mission accomplie !

Pour conclure

J'espère vous avoir convaincu de la puissance des systèmes de fichiers. En particulier, le fait de pouvoir les empiler permet d'obtenir des fonctionnalités très évoluées tout en gardant des briques relativement simples. C'est donc un bon exemple de la philosophie UNIX...

Dans une seconde partie, je vais vous montrer que ces « briques » ne sont pas seulement faciles à utiliser, mais aussi faciles à concevoir...