Linux sur Compact Flash – protéger la flash – ram disk

Bon, le problème des Compact Flash et des flash en général, c’est que les écritures ont tendance à  les user. Il est donc préférable de les protéger en réduisant les ecritures. En général, sur Linux, les répertoires qui sont couremment accédés en écriture sont:

  • /tmp : les données sont ici totalement volatiles, donc on pourra les mettre en ram pour eviter l’usure
  • /home : de toute façon pour un PC de bureau, les données utilisateurs ne tiennent pas sur une CF, un disque réseau viendra à  notre secour
  • /var : les données ici sont plus ou moins volatiles et peuvent être costaud, donc le ramfs n’est pas top, à  voir mais une solution de type unionfs avec nfs et un stockage des élément modifiés sur disque réseau pourrait être une solution… Ce point étant le plus sensible on verra plus tard
  • swap : celui là  peut vite être mortel… Si la machine à  pas mal de mémoire, il y a des chances qu’il ne soit pas trop solicité et c’est donc là  une solution. Pour être sûr, on pourrait carrement le couper ; pour ma part, je le garde pour le cas où mais en utilisation normale, il est utilisé à  0% car ma taille mémoire est sur-sizée… Dans le cas où le swap serait plus solicitable, je pense que son installation sur une seconde CF de plus petite taille et de plus bas prix serait une solution acceptable … à  voir ; mais dans tous les cas à  70€ les 2Go de mémoire autant ajouter de la RAM.

Commençons par voir ce qu’il en est du /tmp … Je propose de la mettre dans un ram-fs et à  mon avis, 512Mo devraient suffir. Les ramdisk étaient des périphériques que l’on trouvait sous le nom __/dev/ram0-15, ils avaient une taille par defaut définie par un paramètre au démarrage du système. Dans mon cas, où j’aurai souhaité créer un ramfs de 512Mo, j’aurai dû ajouter dans mon fichier grub, “menu.lst” le paramètre suivant : ramdisk_size=512000, ce qui aurait donné :
kernel /boot/vmlinuz-2.6.22.13-0.3-custom root=/dev/disk/by-id/… ramdisk_size=512000

Cependant, avec les nouveaux noyau comme le 2.6.23, les ramfs ont été revu, maintenant, il suffit simplement de mettre dans le fichier fstab des entrées de la sorte :
ramfs /tmp ramfs default 0 0

Il semble que la mémoire soit allouée dynamiquement au fur et à  mesure et non reservée. malheureusement, les commandes de type df ne fonctionnent pas. RamFS a ainsi l’air d’être un filesystème et non un pseudo périphérique ce qui permet de ne pas avoir à  le formater … Pas mal d’avantge donc. La taille maxi devrait pouvoir être fixé à  l’aide de l’option maxsize=1000

J’ai un peu de ma à  trouver une bonne description du mode de fontionnement de ramfs, il semble que ce système ait été revu dans les dernieres versions de noyau et la doc n’est pas des plus claire. Toutefois, on peu parlé des autre systemes équivalent.

Dans la même famille, il y a le tmpfs, qui a la bonne idée de pouvoir avoir une taille fixe et qui peut être swappé au besoin. Les tmpfs peut aussi être retaillé à  la volé. Bref c’est une version amélioré du ramfs d’origine. Tmp fs peut être monitoré avec la commande df contrairement à  ramfs.

J’avais lu qu’il pourrait être utile d’utiliser un système de fichier type JFFS2 plutôt que ext2 ou ext3, ce système pouvant permettre des écritures aléatoires sur la flash pour éviter de trop “user” le composant. Toutefois, j’ai aussi lu ceci : “JFFS2, ce FS ne travaille pas sur un block device mais sur un MTD (Memory Technology Device) qui travaille directement au niveau des blocs flash, ce qui est impossible avec une CF ou une clé USB, le contrôleur flash s’occupant de l’interface. Et même si c’était possible ce serait inutile et userait la flash car ce contrôleur gere aussi le wear leveling.” … Du coup n’ayant pas eu l’occasion d’expérimenter, je ne saurait que dire, si ce n’est que celui qui connaît le file système le plsu adapté aux flash ou SSD me le fasse savoir !

Si votre usage est plutôt embarqué de type routeur par exemple, il faut jeter un oeil du coté d’union-fs qui permet par exemple d’avoir un système en read-only sur la flash tout en laissant aux application la possibilité d’écrire sur le système de fichier, au travers d’un ramfs par exemple monté en union. La sauvegarde de certain fichiers particulier (log, config) etan toujours possible sur la flash ou ailleurs, à  tout moment. C’est je pense LA solution à  envisager en embarqué, pour de la bureautique, cette solution pose un problème : la synchro lors de l’installation de paquets, malheureusement fréquente.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.