choisir son file system
Par gblanc le jeudi, juillet 24 2008, 11:58 - linux embarqué - Lien permanent
Je range ce billet dans la catégorie "Linux embarqué" même si cela concernait plutôt "Linux" tout court à la base : en effet, me rendant hier dans un magasin à l'enseigne au nom de corsaire (mais de pirate, la nuance est d'importance par les temps qui courent), j'ai pu regarder les entrailles d'un Acer One exposé (faute de pouvoir en acheter un : la bestiole a eu tellement de succès que la rupture de stock ne s'est pas faite attendre, il faudra attendre une semaine avant d'en revoir). Il s'agit donc d'un mini-portable, que l'on nomme à présent "Netbook" ; pas grand chose d'embarqué a priori, mais à y regarder de plus près, il n'y a pas de disque dur mais une mémoire flash. Comme dans l'embarqué.
Un petit coup d'oeil dans /proc/mount (via l'explorateur de fichier, faute de console disponible) montre alors de bien étranges idées. D'abord, la présence d'une partition swap : 1Go réservé en fin de flash. Ciel ! Quelle idée ! Mettre une partition swap sur de la flash, c'est une des question du partiel que je donne à mes étudiants : c'est une très mauvaise idée. En embarqué, on peut déjà justifié ça par le fait que le système doit de toute façon être dimensionné, et donc la RAM doit correspondre à l'usage que l'on fait de l'appareil. Mais avec l'apparition d'éléphants comme Firefox ou OOo, les 512Mo (mon dieu, et dire que j'ai travaillé sur 12Mo...) peuvent ne pas suffirent dès que le multi-tâche est en jeu. Sauf que voilà : des écritures répétées à des endroits spécifiques de la Flash peuvent l'user jusqu'à rupture des secteurs. Souvent, c'est 100.000 cycles, et ceux qui ont fait de la javacard en stockant des données de capteurs en Flash se mordent souvent les doigts assez rapidement dès que les signes de vie commencent à manquer. Pour la peine, quand on sait à quel point les applications suscitées consomment de mémoire, et que l'on imagine quelqu'un switchant d'une appli à l'autre, forçant les échanges RAM-swap en permanence, on sent bien que d'ici quelques années pas bien nombreuses la Flash va tout simplement rendre l'âme, ce qui est dramatique, puisque c'est soudé dans la machine.
Une bonne idée aurait été de copier sur Nokia, et de se servir de la carte SD que l'on peut insérer comme espace de stockage supplémentaire (l'Acer One dispose de deux lecteurs de cartes SD, une d'extension de stockage, l'autre de lecteur de média amovible) avec un petit coup de dd et de mkswap pour monter une partoche de swap dessus, qui au pire si elle fusille des secteurs, sera changeable facilement. Mais il aurait fallu un peu de dev (un jour pour une personne...).
L'autre mauvaise idée d'Acer est d'avoir mis le système sur la même partition par défaut que le home (si mes souvenirs sont bons), et surtout (là j'en suis sûr), le tout sur du ext2. Oui, un système non prévu pour de la flash (derrière un contrôleur ? On espère), et surtout non journalisé. Embêtant pour un système sur batterie (ne tenant que 3h, le miracle de l'Atom n'est pas arrivé -- tant mieux, ça ne rognera pas trop sur le marché de ARM comme ça, moins il y a de x86 et mieux on se porte), qui peut donc lâcher à n'importe quel instant, corrompant alors le système de fichier ! Si l'on suspecte que c'est pour économiser de l'espace disque (dont on ne dispose que 8Go, moins les 1Go de swap), un arrêt brutal n'est clairement pas conseillé... Et pour la peine, j'ai essayé (la mise en veille semble un peu foireuse...), et après un fsck au démarrage (silencieux, pas moyen de virer le frame buffer d'attente), suivi d'un redémarrage (oh, un BIOS, quelle horreur... Oui, le redémarrage est aussi une spécialité complètement inutile de Nokia, soyons bourrin, d'ailleurs ces derniers ont un bug sur le N770 puisqu'il peut arriver que la machine reboote jusqu'à épuisement des batteries), OOo n'a pas pu rattraper la perte de document (il ne trouvait même plus le fichier, qui pourtant n'avait pas changé de place, si quelqu'un sait d'ailleurs comment virer le rattrapage au démarrage de l'application, qui se lance à chaque fois pour échouer autant de fois, ça m'intéresse), une preuve indéniable de la mauvaise idée que cela représente.
Entre JFFS2 ou YAFFS (pour rester RW, même si je recommande toujours d'avoir un coeur de système RO, et les applis supplémentaires à part sur une partition RW, pour une sécurité optimale), ils auraient pu faire un effort. Il y a encore du chemin à parcourir avant que les constructeurs-intrégateurs fassent attention à ce qu'ils bidouillent... (mais ils peuvent faire appel à Linagora, ce n'est pas interdit :) )
Commentaires
"Sauf que voilà : des écritures répétées à des endroits spécifiques de la Flash peuvent l'user jusqu'à rupture des secteurs. Souvent, c'est 100.000 cycles, et ceux qui ont fait de la javacard en stockant des données de capteurs en Flash se mordent souvent les doigts assez rapidement dès que les signes de vie commencent à manquer."
Un SSD implemente normalement des fonctions de wear leveling qui permettent de repartir la charge equitablement sur tout ou parti du disque. La limite des 100 000 cycles par block est donc très dure à atteindre (il faut, selon les procédés, atteindre 99 999 sur tous les blocks du disques, ou juste ceux de la zone)
On peut legitimement penser, au vue de l'evolution des technologies, que dans 4 ou 5 ans, le disque sera changé, et n'aura pas souffert d'une config malheureuse.
Oh, un premier commentaire, enfin ! :) Effectivement le x86 attaque la flash derrière un contrôleur (d'ailleurs, je ne sais même pas s'il est possible de faire ça autrement) : on peut le voir au fait que les points de montage sont en /dev/sd* et non en /dev/mtdblock* (comme on l'aurait sur une archi ARM, le bonheur). Or ces contrôleurs effectuent bien du leveling en hard, c'est même obligatoire pour les clés USB, car comme nous le savons celles-ci sont formatées par défaut selon le dénominateur commun à tous les OS depuis Win95 : l'abominable FAT32, qui en gros ne gère rien, et surtout pas le leveling.
Sauf que notre problème n'est pas levé pour autant : les file systems (autre que le système lui même, sujet à peu de modifications) sont tout petits ! Déjà, 1Go de swap, avec du Firefox et du OOo, ça risque de mal se passer (ayant un N770 où il y a possibilité de monter une partition swap sur la mini SDCard, je peux dire que dès que l'on ouvre plus de 4 fenêtres Opéra, c'est rapidement sollicité, et pas qu'un peu). Quatre ou cinq ans avant de mourir, je crois que ce sera pour ceux qui n'utilisent leur système que de manière modérée. Avec un peu de chance c'est de la compact flash qui se change en ouvrant juste le boîtier (tout le monde ne s'appelle pas Apple et soude même la batterie), mais c'est quand même pas la panacée. En fait, c'est encore du jetable, comme d'hab...
Et puis même cinq ans de durée de vie, c'est à pleurer pour quelqu'un qui fait de l'embarqué :(. Bref, il vaut mieux augmenter la RAM et ne pas mettre de swap, en espérant que les données utilisateur sur le disque (partition home) ne bougeront pas trop (problématique similaire à une clef usb, à ce moment-là, mais plus on a de place, plus ça permettra à la fois d'avoir des données qui ne bougeront pas beaucoup d'un côté, et de l'autre de la place pour faire du leveling pour les fichiers qui connaissent beaucoup de cycles d'écriture). Et puis ça permet au passage de libérer de l'espace pour mettre en place la journalisation du FS, ce qui n'est jamais du luxe sur un matériel à l'autonomie limitée (et pas bien déterministe).
Personnellement, j'attends l'Acer One avec disque dur. Je m'imagine mal de toute façon coincé avec 2Go d'espace pour le stockage de données (on peut stocker à peine trois films en divx ! Ah non c'est mal), même ma clef USB en fait 8 (mais en FAT32, quelle misère), et quand on sait qu'un Linux décompressé fait plus de 200Mo... (tout dépend de l'utilisation, comme d'habitude, personnellement se sera pour donner des cours, donc stocker au moins un OpenEmbedded complet, ce qui fait plusieurs gigas : et hors de question de compiler sur de la flash, là ce n'est plus quatre ans mais quatre mois avant décès !)
A noter aussi qu'utiliser CRAMFS/JFFS2/YAFFS et consorts est mieux en l'occurrence pour leur qualité de résistance aux coupures brutales et pour le fait qu'ils sont compressés (pour la partiton root, on gagne quasiment 50% de place !), beaucoup moins parce qu'ils gèrent le leveling (je ne sais pas s'il existe des comparaisons d'algo/efficacité entre les solutions hard et soft, notamment il serait intéressant de voir la fragmentation engendrée, et de fait les effets sur la vitesse du système à accéder aux fichiers).