Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Les systèmes POSIX ont l'intérêt d'identifier clairement /var comme le dossier système dont les fichiers sont modifiés le plus fréquemment. Ainsi, si l'on monte /var et /home sur les partitions d'un disque mécanique, l'usure du SSD sur lequel est monté la racine du système est grandement réduite.
, ce qui me fait me/vous poser la question suivante : si l'idée est de minimiser les écritures sur le ssd, qu'en est-il des dossiers /dev, /proc, /run, /sys ?
Parce que ces 4 dossiers, pleins de trucs et de machins, quand on les examine dans une machine virtuelle éteinte, ils sont vides ! Ce qui veut dire qu'ils sont remplis à grands coups d'écritures maudites pour la fiabilité du ssd au boot de la machine.
Le plan serait donc de les déplacer vers un disque mécanique au même titre que /var, /usr (pour ceux qui compilent souvent des noyaux) et /home, et si pour ces derniers une procédure classique serait suffisante (voir ici), qu'en est-il des 4 premiers, qui doivent exister dès le début du boot je suppose ?
Je pense qu'il faut s'appuyer sur initrd pour faire le boulot, mais je n'ai jamais pratiqué.
Des idées, des pistes ?
Merci et bonne journée,
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Hors ligne
si l'idée est de minimiser les écritures sur le ssd, qu'en est-il des dossiers /dev, /proc, /run, /sys ?
/dev et /run sont des systèmes de fichiers temporaires en mémoire (tmpfs).
/proc et /sys sont des systèmes de fichiers virtuels servant d'interface avec le noyau.
Aucun n'est stocké sur disque. Le contenu des tmpfs peut éventuellement être écrit dans le swap en cas de mémoire insuffisante, mais ce n'est pas différent des autres données en mémoire.
Parce que ces 4 dossiers, pleins de trucs et de machins, quand on les examine dans une machine virtuelle éteinte, ils sont vides ! Ce qui veut dire qu'ils sont remplis à grands coups d'écritures maudites pour la fiabilité du ssd au boot de la machine.
Non, cela veut dire que dans le système de fichiers racine ce ne sont que des points de montage. Même chose avec /home s'il est sur une partition séparée.
Le plan serait donc de les déplacer vers un disque mécanique au même titre que /var, /usr (pour ceux qui compilent souvent des noyaux) et /home
Ça devient vraiment n'importe quoi, cette obsession avec l'écriture sur les SSD. Ils ne sont pas en sucre. Si tu mets /usr hors du SSD, il ne restera pas grand-chose à y mettre vu qu'il contient la majeure partie des fichiers système.
Il vaut mieux montrer que raconter.
Hors ligne
/proc et /sys sont des systèmes de fichiers virtuels servant d'interface avec le noyau.
Aucun n'est stocké sur disque.
En mémoire, alors ?
Okay, bien noté !
Ça devient vraiment n'importe quoi, cette obsession avec l'écriture sur les SSD. Ils ne sont pas en sucre.
Ah, ce n'est pas moi qui ai commencé ! Faudra en parler aux gens d'Ubuntu (et sans doute à d'autres, je n'ai pas trop cherché), mais cependant ça m'intéresse : curiosité intellectuelle et aussi pour voir si des manips scabreuses peuvent quand même être réalisées, c'est excitant pour les neurones, 
Si tu mets /usr hors du SSD, il ne restera pas grand-chose à y mettre vu qu'il contient la majeure partie des fichiers système.
Je pourrais me contenter de /usr/src alors.
Merci pour tes précisions, 
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
En mémoire, alors ?
Non, les pseudo-fichiers de /proc et /sys ne sont stockés nulle part. Ils servent à déclencher des actions du noyau quand on y accède en lecture ou en écriture.
Je pourrais me contenter de /usr/src alors.
Ou bien tu peux compiler ailleurs que dans /usr/src (ce que je fais). Mais ce serait dommage de se priver de la vitesse du SSD pour accélérer la compilation, non ? Tu peux aussi compiler en tmpfs ou en zram si tu as assez de mémoire.
Il y a deux sortes de données : celles dont l'accès n'a pas d'impact sur les performances globales, et celles qui en ont un. Par exemple, les logs de /var/log n'en ont pas parce qu'il est rare qu'on les relise. Par contre /var/lib et /var/cache contiennent des données qui sont lues fréquemment. La première catégorie peut être exclue du SSD. Bien évidemment le swap entre dans la seconde catégorie.
Il vaut mieux montrer que raconter.
Hors ligne
Non, les pseudo-fichiers de /proc et /sys ne sont stockés nulle part. Ils servent à déclencher des actions du noyau quand on y accède en lecture ou en écriture
Là j'ai besoin d'un soupçon d'explications complémentaires car on m'a bien dit au tout début de ma découverte de cet éco-système, que sous Linux tout est fichier et les choses dont tu parles ne sont stockées nulle part ! Mais comment ça fonctionne, alors ? Si ton temps est compté, ne te prends pas la tête, un lien me suffira.
Ou bien tu peux compiler ailleurs que dans /usr/src (ce que je fais). Mais ce serait dommage de se priver de la vitesse du SSD pour accélérer la compilation, non ?
Il y a un tel écart ?
Tu peux aussi compiler en tmpfs ou en zram si tu as assez de mémoire.
16 Go, ça devrait le faire, mais pareil qu'au premier point, un poil d'explications complémentaires please, juste pour ne pas me ramasser à la première tentative exotique.
Quant aux performances globales, l'usure du ssd toussa toussa, il me semble me souvenir qu'il y a en gros trois types de techno pour ces fichues cellules de ram, une qui dure longtemps, une un peu moins et une autre c'est ridicule, elle est donnée pour 1000 écritures fiables et après faut croiser les doigts. 1000 écritures à 1 par jour à la louche ça fait 3 ans.
À comparer avec les disques méca en prod à l'heure actuelle (des 1 To tout ce qu'il y a de plus basique en sata) qui doivent avoir 10 ans d'âge et toujours vaillants !
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
sous Linux tout est fichier et les choses dont tu parles ne sont stockées nulle part !
Oui, tout est fichier. Mais de façon générale, l'arborescence des répertoire et des fichiers n'est qu'une abstraction présentée par le noyau. Dans le cas d'un système de fichiers classique comme ext4, il s'agit de vrais objets stockés dans de vrais blocs de mémoire, et le noyau fait la traduction entre le chemin d'un fichier et les blocs qu'il occupe. Mais il peut tout aussi bien, dans le cas d'un système de fichiers virtuel, faire une traduction entre le chemin d'un pseudo-fichier et n'importe quoi qu'il va présenter comme le contenu du fichier. Par exemple si on lit /proc/mounts, le noyau va renvoyer la liste des systèmes de fichiers montés. Si on lit /sys/block/sda/size, le noyau va renvoyer la taille du disque sda. Si on écrit "3' dans /proc/sys/vm/drop_caches, le noyau vide ses caches disques. Le "contenu" de ces pseudo-fichiers n'est pas stocké tel quel dans la mémoire ni sur disque, il est généré par le noyau à partir de ses données à chaque lecture, comme le ferait un programme avec la fonction printf(), ou interprété en action dans le cas d'une écriture.
J'espère que c'est assez clair.
Il y a un tel écart ?
Ça dépend. Il faut tester et comparer pour le savoir.
Tu peux aussi compiler en tmpfs ou en zram si tu as assez de mémoire.
un poil d'explications complémentaires
tmpfs est un type de système de fichiers temporaire en mémoire (et dans le swap si pas assez de mémoire, d'où l'intérêt du swap sur SSD). C'est utilisé par défaut pour /dev dont le contenu est géré dynamiquement par udev, et /run qui ne contient que des données d'exécution temporaires. Cela peut être aussi utilisé pour /tmp. La taille par défaut d'un tmpfs est de 50% de la RAM, mais la quantité de mémoire réellement occupée dépend du contenu, un tmpfs de 8 Go vide n'occupe presque pas de mémoire. En fait, tmpfs c'est du cache disque sans disque.
zram est un disque RAM compressé. C'est utilisable notamment comme swap avec le paquet zram-tools (très mal nommé, il devrait s'appeler zram-swap), mais pas seulement. C'est un périphérique bloc donc une fois créé il faut le formater avec système de fichiers comme ext4 pour le monter comme le disque RAM traditionnel, mais il a deux avantages : il compresse les données en mémoire et il supporte l'abandon (discard) pour libérer la mémoire des blocs qui ne contiennent plus de données utiles, comme la fonction TRIM des SSD, à condition d'utiliser un système de fichiers qui le supporte aussi. La compression/décompression à la volée charge le CPU, mais c'est à comparer avec les temps de lecture et d'écriture sur un support de stockage.
Une compilation produit de nombreux fichiers intermédiaires (comme les .o) qui n'ont pas besoin d'être conservés. On peut donc les mettre sur un tmpfs ou un zram.
il me semble me souvenir qu'il y a en gros trois types de techno pour ces fichues cellules de ram, une qui dure longtemps, une un peu moins et une autre c'est ridicule, elle est donnée pour 1000 écritures fiables et après faut croiser les doigts. 1000 écritures à 1 par jour à la louche ça fait 3 ans.
Tu parles de SLC, MLC et TLC. 1000 cycles d'effacement/écriture cela peut sembler peu, mais tu n'écris probablement pas un volume équivalent à la capacité du SSD chaque jour, donc ton SSD durera plus que 3 ans. Ce qu'il faut considérer, c'est le volume total d'écritures, parfois exprimé en TBW (tera-bytes written) dans les spécifications et les attributs SMART. Pour un disque de 120 Go supportant 1000 cycles, on pourra écrire jusqu'à 120 To. Et 1000 n'est qu'un ordre de grandeur, ça pourrait aussi bien être 2000.
Il faut se poser la question : quel volume de données mon système écrit-il par jour, pas semaine, pas mois, par an ?
Il vaut mieux montrer que raconter.
Hors ligne
--snip--
Il faut se poser la question : quel volume de données mon système écrit-il par jour, pas semaine, pas mois, par an ?
Noooooooooooooooooooon !
C'est quand que j'utilise mon ordi pour
- créer des compils audio pour la chérie,
- retoucher des images en prévision d'un book, toujours pour la chérie,
- lui préparer affiches et invitations pour ses futures expos, si elles ont lieu,
- reprendre le montage de films familiaux 8 et Super8 numérisés à destination d'un dvd,
- continuer à étudier les espaces de couleurs et particulièrement le RJB, plus proche de la peinture que le RVB,
- travailler la gestion des polices sous Linux,
- aider une copine pour la mise en page d'un livre,
- et j'en oublie tout plein...
Merci pour tout, raleur, j'ai du pain sur la planche, on dirait, 
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Dernière modification par anonyme (22-04-2021 18:23:12)
Hors ligne
pour le mien, le constructeur annonce 800 TBW. Je ne crois pas arrivé au bout même avec mon usage.
Cela équivaut à 200 Go par jour pendant 10 ans. Largement suffisant pour de nombreux cas d'usage.
les pannes des ssd sont plus prévisibles que sur les disques mécaniques ?
La défaillance due à l'usure devrait être prévisible puisque celle-ci est mesurée par les attributs SMART. Par contre je crains que les pannes d'origine électronique soient plus brutales que les pannes d'origine mécanique.
par rapport à l'usure, est-ce qu'il serait préférable d'envisager certains système de fichiers ?
Vaste débat. A ma connaissance il n'y a pas de consensus sur le sujet. Les systèmes de fichiers dits "structurés en log" (log-structured filesystems) sont a priori plus adaptés aux supports de stockage à mémoire flash. Il en existe deux catégories :
- Les systèmes de fichiers conçus pour la mémoire flash brute (memory technology device ou MTD) comme jffs2 et ubifs sont hors sujet car les SSD sont vus comme des périphériques de type bloc.
- Les systèmes de fichiers conçus pour les périphériques de type bloc comm les SSD, clés USB et cartes SD. Ceux que je connais sont f2fs et nilfs2.
On peut éventuellement mentionner UDF dont le format originellement conçu pour les disques optiques réinscriptibles pourrait être adapté aux supports à mémoire flash.
f2fs et nilfs2 ont plusieurs inconvénients :
- Ils ne sont pas pris en charge par l'installateur Debian (du moins jusqu'à la version 10, je ne sais pas pour bullseye). Si on veut les utiliser pour le système, il faut faire l'installation sur un système de fichier supporté puis la copier sur le système de fichiers final et faire les modifications de fichiers système nécessaires (fstab, initramfs, grub...).
- Ils ne sont pas pris en charge nativement par l'initramfs de stretch, mais on peut l'ajouter.
- f2fs n'est pas pris en charge par GRUB avant la version de bullseye ; si on l'utilise pour la racine, il faut donc un /boot séparé avec un autre système de fichiers pris en charge par GRUB.
- D'après certains témoignages, le format de f2fs ne serait pas stable entre les versions de noyau, conduisant à des incompatibilités ou des corruptions de données.
- Le "garbage collector" de nilfs2 doit être réglé pour libérer l'espace disque plus vite qu'on ne le remplit.
- nilfs2 ne supporte pas les attributs étendus de fichiers, utilisés notamment pour stocker les "capacités" (man capabilities) de certains exécutables comme ping (à défaut le paquet appliquera le bit SUID).
D'autre part ils sont conçus en partant du principe que le périphérique de stockage est "idiot". Or les SSD ont un contrôleur intégré qui gère la mémoire flash de façon intelligente. C'est pourquoi leurs avantages par rapport aux systèmes de fichiers "classiques" sont discutés. Si on reste avec les systèmes de fichiers classiques, on peut préférer ceux qui supportent TRIM/discard comme btrfs, ext4 et xfs. Là encore il n'y a pas consensus sur l'utilité de TRIM avec les SSD actuels (sans parler de la stratégie "online" ou "batch" à appliquer), celui-ci étant accusé de dégrader les performances. TRIM est utile si on supprime des données et qu'il se passe un certain temps avant d'écrire de nouvelles données à la place.
Il vaut mieux montrer que raconter.
Hors ligne
Par contre je crains que les pannes d'origine électronique soient plus brutales que les pannes d'origine mécanique.
Ah ouais, les diodes de protection qui claquent !
https://fr.harddriveparts.com/changer_c … e_dur.html
https://fr.harddriveparts.com/100716565 … epair.html
Mais faut pas avoir deux mains gauches, sur ce coup-là ! 
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne