Journal Un ramdisk pourquoi faire ?

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
22
18
nov.
2023

Bonjour,

Depuis quelque temps un ramdisk, c’est-à-dire un système de fichier en RAM est apparu dans mon arborescence Linux. Je suppose que l’augmentation de la RAM disponible couplée à l’usage de SSD limités en cycle d’écriture, ne sont pas étrangers à cette nouveauté.

Au départ, je n’ai pas porté une attention particulière à cette fonctionnalité. Juste, comme indiqué ci-dessus, je me suis fait la réflexion que ça économise le disque et doit aussi accélérer le système. Mais cela sans penser à ce que je pourrais faire de plus de cet espace de travail très temporaire.

Avec le temps, je l’utilise de plus en plus, car justement, c’est automatiquement effacé lors de l’arrêt du système et ça évite l’accumulation de choses dont on ne se sert pas ou trop peu. Par exemple, je veux récupérer une photo sur un site où il est impossible de l’enregistrer avec un click droit. Dans ce cas, j’enregistre toute la page dans le ramdisk, je récupère l’image. Le reste sera effacé lors de l’arrêt de mon ordi.

Autre exemple, je compile beaucoup de documents en LaTeX et metapost. Ces logiciels créent des fichiers (très) temporaires dans le répertoire courant. Pour éviter leur écriture furtive sur le SSD, je compile mes documents dans le ramdisk.

Un script manipule des fichiers et doit créer des fichiers temporaires, autant le faire dans le ramdisk. Même si le script « oublie » de les effacer. Ils le seront automatiquement lors de l’arrêt de la machine.

Ce sont mes principales utilisations personnelles du ramdisk. Et vous quelles sont les vôtres ?

  • # /tmp

    Posté par  . Évalué à 10.

    Sur ma distrib, cela fait bien longtemps que /tmp est monté en ram (device tmpfs).
    C'est surement ton cas également.

    Je me sers de /tmp comme ramdisk, pour les mêmes raisons que toi.
    Je trouve le nom tellement parlant que si je m'étais monté mon propre ramdisk, je crois que je l'aurait appellé « tmp » également :)

    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: /tmp

      Posté par  . Évalué à 5.

      De mémoire, le répertoire /run/users/$uid est aussi un ramdisk lisible uniquement par l'utilisateur.
      J'ai pris l'habitude de me faire un lien tmp dans mon home vers ce répertoire pour y mettre mes fichiers de travail

    • [^] # Re: /tmp

      Posté par  (Mastodon) . Évalué à 10. Dernière modification le 18 novembre 2023 à 22:11.

      Attention à ramdisk et tmpfs, c'est pas pareil.

      Le ramdisk est un disque émulé en RAM, c'est à dire qu'il réserve en RAM dès la création sa taille complète, qu'il soit utilisé ou non. Le tmpfs lui au contraire prend ce dont il a besoin au fur-et-à-mesure du besoin (dans une limite maximale).

      De plus il me semble (à vérifier) que tmpfs est swappable là ou le ramdisk ne l'est pas.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: /tmp

        Posté par  . Évalué à 1.

        Je ne sais pas comment tu distingues ramdisk de tmpfs, car pour ma part quand je crée un ramdisk pour mon usage (sans toucher aux autres de base comme "/run"), il est de type tmpfs et ne prend pas de mémoire s'il est vide ; ensuite la mémoire est allouée en fonction des fichiers que j'y mets. J'ai un ramdisk de 7 Go (mon ordi a 16 Go au total), la commande "free" montre bien que ça ne prend que la place des fichiers qui y résident.

        • [^] # Re: /tmp

          Posté par  . Évalué à 2.

          Ce dont il parle c'est d'avoir un périphérique de type block (un /dev/sd* par exemple) qui représente un bloque de mémoire et qui justement (comme une partition) est alloué à la création (l'espace n'est pas considéré comme libre par l'OS) et peut peux ensuite choisir de le formater avec mkfs en ext, xfs ou le système de fichier que tu veux.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: /tmp

            Posté par  . Évalué à 1.

            Ah OK merci, mais je ne vois pas l'intérêt d'un tel truc. Le tmpfs est parfait pour le besoin de stocker en RAM avec la rapidité associée (et pour ceux qui sont un peu parano sur la Flash, pour moins écrire dessus).

    • [^] # Re: /tmp

      Posté par  (site web personnel) . Évalué à 10.

      /tmp n'est pas en tmpfs par défaut sur Debian.

      Je suis tombé sur ce résumé en cherchant pourquoi.

      blog.rom1v.com

      • [^] # Re: /tmp

        Posté par  (Mastodon) . Évalué à 5.

        Très intéressant à lire, merci pour le lien !

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # SSD et usure

    Posté par  . Évalué à 10.

    l’usage de SSD limités en cycle d’écriture

    Même si cela existe effectivement, il faut bien garder en tête les ordres de grandeur dont on parle.

    Prenons comme exemple un SSD de 1To: on trouve, assez classiquement, des limites de l'ordre de 600TB (en donnée constructeur).

    Il faut bien voir que ce nombre est très grand: même en écrivant l'équivalent de 50Go chaque jour sur le disque, on aurait une durée de vie de l'ordre de 30 ans !

    Pour moi le ramdisk est effectivement utile pour sa vitesse, et ce côté volatile. Mais pas pour "sauver" le SSD.

    • [^] # Re: SSD et usure

      Posté par  . Évalué à -4.

      Je sais qu'à l'heure actuelle le nombre de cycle d'écriture est conséquent et difficilement atteignable en usage normal.

      Mais parfaois, il vaut mieux prendre les devants, une boucle infinie qui écrit sur le disque et les compteurs peuvent vite s'affoler.

    • [^] # Re: SSD et usure

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Oui et non. 50 Go par jour, ce n'est pas tant que ça. Sais tu qu'un simple fichier Word, qui n'est en soit que du texte fait facilement plusieurs Mo disons 10 et qu'il est compressé, pour l'ouvrir LireOffice le decompresse soit 100Mo. Ensuite en travaillant dessus on a tellement de réécriture dans tout les sens que l'on atteint bien le Go. Ça reste loin des 50 Go mais qu'en est il si on travail avec des images ou des films… ou que l'on code. 50 Go ce n'est vraiment pas grand chose aujourd'hui. Pour rester informatique, travaillons avec des docker…

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

      • [^] # Re: SSD et usure

        Posté par  . Évalué à 5.

        Combien de données sont réellement écrites sur disque dans cet interval ? Les caches mémoires des disques sont plutôt efficaces de mon expérience

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: SSD et usure

          Posté par  . Évalué à 2.

          C'est la question que je me pose quand je vois la durée de vie des fichiers temporaires de LaTeX et Metapost. Ils sont créés et effacés quelques secondes après. Ont-ils "vécus" assez longtemps pour être transférés sur le disque SSD?

    • [^] # Re: SSD et usure

      Posté par  . Évalué à 4. Dernière modification le 18 novembre 2023 à 21:06.

      la RamDisk peut être utilisée sur des systèmes embarqués, dans le cas ou on n'a pas besoin d'écrire beaucoup de donées sur disques lors du fonctionnement du système. On peut dans ce cas utiliser un système de stockage ROM (ou flash), ou un système de stockage plutôt lent, et utiliser la RamDisk comme disque d'écriture de données temporaires. Par contre il faut voir au cas par cas car il n'est pas forcément évident que de la RAM coûte moins cher que du stockage persistent style SSD : ça va dépendre de la quantité de données à écrire sur le support.

    • [^] # Re: SSD et usure

      Posté par  . Évalué à 10.

      Pour mon Samsung 860 EVO 500GB, S.M.A.R.T me dit :

      Total_LBAs_Written: 83995540294

      Ça fait 83995540294*512B = 43005716630528B ~= 39TB.

      Je l'ai acheté il y a 5 ans. Le TBW annoncé par Samsung est de 300TB. À ce rythme, il faudrait 300*5/39 ~= 38 ans pour l'atteindre, donc j'ai encore 33 ans devant moi. Il n'est pas impossible que le SSD claque après moi :)

      Il faut vraiment arrêter de se prendre la tête à ne pas utiliser son SSD : l'époque des SSD de 40Go tout moisis qui claquaient en 3 mois est loin derrière nous.

      • [^] # Re: SSD et usure

        Posté par  . Évalué à 3. Dernière modification le 22 novembre 2023 à 09:50.

        Mon laptop pro précédent était à 99% de la limite après ~4 ans pour certaines cellules. Je n'ai aucune idée de ce que j'ai fait pour causer autant d'écritures mais apparemment on peut y arriver. Je pense que c'est lié au fait que le disque de 256G était plein à 90% la plupart du temps, ce qui fait que les cellules vides ont pris cher parce que le wear leveling ne pouvait pas fonctionner correctement dans ces conditions.

        En d'autres termes, pour vivre longtemps un SSD ne doit pas être remplis à ras bord de données qui changent peu, il vaut mieux avoir un disque à moitié vide. J'ai d'ailleurs déjà vu des articles qui préconisaient de ne pas partitionner l'ensemble de l'espace disponible.

      • [^] # Re: SSD et usure

        Posté par  . Évalué à 1.

        Il faut vraiment arrêter de se prendre la tête à ne pas utiliser son SSD : l'époque des SSD de 40Go tout moisis qui claquaient en 3 mois est loin derrière nous.

        Je pertinente totalement, ça m'étonne toujours de voir des gens qui ont l'impression qu'ils vont user leur SSD, avec du swap en particulier.

        J'ajoute que je n'ai pas connu cette époque des SSD "qui claquaient en 3 mois" ; ça m'étonne beaucoup car mon premier SSD de 80 Go en 2009 - il y en avait encore peu - était en SLC ou MLC d'une part, et a tenu plus de 10 ans comme disque système Linux, avec le swap dessus.

  • # Je ne parlerai qu'en présence de mon avocat

    Posté par  (Mastodon) . Évalué à 5. Dernière modification le 18 novembre 2023 à 18:30.

    Depuis quelque temps un ramdisk

    On attend le résultat des commandes mount et df pour savoir de quoi on parle précisément.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Je ne parlerai qu'en présence de mon avocat

      Posté par  . Évalué à 1.

      $ mount|grep tmpfs
      devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,size=1828072k,nr_inodes=457018,mode=755,inode64)
      tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,inode64)
      tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,mode=755,inode64)
      tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=1882396k,nr_inodes=1048576,inode64)
      tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=376476k,nr_inodes=94119,mode=700,uid=1000,gid=1000,inode64)

      1 828 072k + 1 882 396k + 376 476k !

      Heureusement que ça ne réserve pas tout, je n'aurais plus de RAM du tout…

  • # Question

    Posté par  . Évalué à 4.

    Par exemple, je veux récupérer une photo sur un site où il est impossible de l’enregistrer avec un click droit.

    Et avec shift + clic droit ?

    • [^] # Re: Question

      Posté par  . Évalué à 1.

      Non, je ne connaissais pas. Je tenterai la prochaine fois.

    • [^] # Re: Question

      Posté par  . Évalué à 9.

      moi j'utilise ctrl-i sous firefox, puis je prends l'onglet média ;)

      et je cherche l'image en question :D

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Question

      Posté par  . Évalué à 0. Dernière modification le 19 novembre 2023 à 17:15.

      Sous Firefox, suivant le contexte, j'utilise aussi parfois l'onglet 'Médias' de la fenêtre 'Information sur la page' pour pouvoir enregistrer des images.
      Pas forcément quand le click droit est désactivé sur le site, mais par exemple quand une image est affichée en popup et qu'un click droit ferme la popup.

      Ah, juste devancé par fearan

      • [^] # Re: Question

        Posté par  . Évalué à 1.

        Comment affiches-tu cet onglet ?
        J'aimerais tester cette solution.

        • [^] # Re: Question

          Posté par  . Évalué à 2. Dernière modification le 22 novembre 2023 à 13:58.

          Pour avoir la fenêtre "informations sur la page", il suffit de faire ctrl+I. - cf le message de fearan

    • [^] # Re: Question

      Posté par  (site web personnel) . Évalué à 2.

      Ne peut-on pas considérer que, si le site n'autorise pas la copie de l'image, celle-ci n'est pas libre de droit d'usage ?

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Question

        Posté par  . Évalué à 9.

        Si elle est un site web que je consulte, mon navigateur l'a déjà téléchargée et stockée quelque part sur mon disque. L'enregistrer revient à la stocker à un autre emplacement en fait… Tant qu'elle n'est pas repartagée ou altérée, je ne vois pas trop ce qu'on pourrait me reprocher.

      • [^] # Re: Question

        Posté par  (Mastodon) . Évalué à 7.

        On ne peut pas limiter ton droit d'usage privé de l'image.

        • [^] # Re: Question

          Posté par  . Évalué à 1.

          C'est totu à fait cela.
          Je comprends que la personne n'est aps envie que l'on exploite son travail.
          Mais je n'ai pas dis que je récupère son image pour mes faire des sous avec !
          Que ce soit pour la mettre en fond d'écran, illustrer un document personnel, ou autre. On a souvent l'occasion d'avoir besoin d'une photo ou d'une image spécifique.

  • # Pas en RAM

    Posté par  . Évalué à 4.

    Ce sont mes principales utilisations personnelles du ramdisk. Et vous quelles sont les vôtres ?

    Personnellement j'utilise mon /tmp pour ça mais il n'est pas en RAM. Il est effectivement nettoyé automatiquement, mais il ne prend pas de place en RAM que je préfère utiliser pour mes applications et le cache disque classique de linux.

    De plus il peut m'arriver de manipuler des dizaines de Gio ça remplirai vite la place.

    J'ai un alias, gotmp, qui fait grosso modo cd $(mktemp -d).

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # ram-pas-disque

    Posté par  (site web personnel) . Évalué à 5.

    Depuis quelque temps un ramdisk,

    Non.

    c’est-à-dire un système de fichier en RAM

    Oui.

    Plus précisément, un sous Linux, un tmpfs est un bien un système de fichiers en mémoire. En revanche, ce n'est pas un ramdisque, c'est à dire que ce n'est pas un morceau de mémoire réservé et présenté comme un périphérique bloc, sur lequel on viendrait mettre un système de fichiers. C'est un système de fichiers bien particulier, directement implémenté en mémoire.

    • [^] # Re: ram-pas-disque

      Posté par  (site web personnel) . Évalué à 1.

      <dino>Sur Amiga, il y a bien longtemps, on avait par contre un vrai RAM disk. J'en faisais une utilisation très intensive, vu le prix des prohibitif des disques durs à l'époque, et la vitesse des accès sur une disquette.</dino>

      • [^] # Re: ram-pas-disque

        Posté par  . Évalué à 1.

        J'ai eu un Amiga et c'était le même principe (le RAM disk prend sur la mémoire RAM quand on y dépose des fichiers, comme pour le tmpfs Linux). Je ne comprends pas la notion de "vrai RAM disk", c'est quoi un faux RAM disk alors ?

    • [^] # Re: ram-pas-disque

      Posté par  . Évalué à 1.

      Merci car avec ton explication, je vois mieux la différence entre les deux, mais je pense que je vais continuer à appeler ce système un RAM disk.Je trouve que c'est plus "parlant". Je sais, ce n'est pas bien !

      • [^] # Re: ram-pas-disque

        Posté par  . Évalué à 1.

        TU as raison d'appeler ça un ramdisk, c'est ce que c'est.

        Pour répondre au commentaire avant le tien :

        c'est à dire que ce n'est pas un morceau de mémoire réservé et présenté comme un périphérique bloc, sur lequel on viendrait mettre un système de fichiers.

        Je ne vois pas l'intérêt de faire un tel type de ramdisk, ça bouffe de la mémoire pour rien.

        C'est un système de fichiers bien particulier, directement implémenté en mémoire.

        C'est le ramdisk que je connais depuis l'Amiga, ça prend sur la RAM à la volée quand on y met des fichiers.

        • [^] # Re: ram-pas-disque

          Posté par  . Évalué à 3.

          Alors déjà c'est plus vieux que les systèmes de fichiers en mémoire.

          Je ne vois pas l'intérêt de faire un tel type de ramdisk, ça bouffe de la mémoire pour rien.

          Pour rien si tu ne connaît pas à l'avance la place que tu va prendre. Ça peut servir à faire de la préallocation.

          Ensuite ça peut servir à utiliser des fonctionnalités que tu n'a pas avec tmpfs comme de la gestion de volume par exemple. Tu peux aussi imaginer avoir un cluster glusterfs qui n'utilise que de la mémoire vive. Tu peu survivre à la perte d'une machine. Je ne sais pas à quel point c'est pertinent j'imagine juste des cas.

          Ça peut servir à tester des systèmes de fichiers si tu es développeur. Tu peux comme ça avoir des tests de ton système qui créent un rmadisk font leur tambouille et le libère à la fin du test (sans besoin d'avoir une partition physique, que l'identification du disque de tests soit bon entre tous les développeurs, etc).

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: ram-pas-disque

            Posté par  . Évalué à 1. Dernière modification le 27 novembre 2023 à 18:08.

            Ça peut servir à tester des systèmes de fichiers si tu es développeur

            Ça me paraît aussi bien de créer un fichier "loopback" en ramdisk (style "tmpfs") avec un "dd" et de le monter pour tester un filesystem.

            L'avantage aussi du ramdisk c'est que sur une machine avec 16 Go de RAM tu peux très bien monter un ramdisk tmpfs avec 14 Go de capacité max, et ça ne prend rien (ou loin de 14 Go) si tu ne mets pas grand chose dedans, tout en permettant (s'il reste jusque 14 Go de RAM libre car seulement 2 Go occupés par tout ce qui tourne) de le remplir.

            • [^] # Re: ram-pas-disque

              Posté par  . Évalué à 3.

              Ça me paraît aussi bien de créer un fichier "loopback" en ramdisk (style "tmpfs") avec un "dd" et de le monter pour tester un filesystem.

              Peut être, mais faut créer le fichier, le supprimer en plus de l'avoir unmount etc.

              L'avantage aussi du ramdisk c'est que sur une machine avec 16 Go de RAM tu peux très bien monter un ramdisk tmpfs avec 14 Go de capacité max, et ça ne prend rien (ou loin de 14 Go) si tu ne mets pas grand chose dedans, tout en permettant (s'il reste jusque 14 Go de RAM libre car seulement 2 Go occupés par tout ce qui tourne) de le remplir.

              Oui oui on a tous compris que tmpfs prends que la place dont il a besoin, ce qui peut d'ailleurs entrainer des surprise quand on s'habitue à faire de l'over provisionning.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Pour le démarrage ?

    Posté par  . Évalué à 4.

    Il n’est pas rare, de démarrer le noyau avec un RAMDISK pour ensuite charger des drivers, déchiffrer un systhème de fichier, etc. . Puis, de faire un pivot_root pour mettre la vrai racine.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.