Quand dois-je utiliser /dev/shm/ et quand dois-je utiliser /tmp/ ?

Dans l'ordre décroissant de tmpfs vraisemblance :

┌───────────┬──────────────┬────────────────┐
│ /dev/shm │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp │ can be tmpfs │ FHS 1.0 │
├───────────┼──────────────┼────────────────┤
│ /var/tmp │ never tmpfs │ FHS 1.0 │
└───────────┴──────────────┴────────────────┘

Puisque vous posez une question sur un point de montage tmpfs spécifique à Linux par rapport à un répertoire défini de manière portable qui peut être tmpfs (selon votre administrateur système et ce qui est par défaut pour votre distribution), votre question comporte deux aspects, que les autres réponses ont mis en évidence différemment :

1. quand utiliser ces répertoires, en se basant sur la bonne pratique
2. Quand il est approprié d'utiliser tmpfs

Bonnes pratiques

Édition conservatrice (mélange de conventions de FHS et d'usage courant) :

• En cas de doute, utilisez /tmp.
• Utilisez /var/tmp pour les données volumineuses qui peuvent ne pas tenir facilement dans la mémoire vive.
• Utilisez /var/tmp pour les données qu'il est utile de conserver pendant les redémarrages (comme un cache).
• Utilisez /dev/shm comme effet secondaire de l'appel à shm_open(). Le public visé est constitué de tampons délimités qui sont sans cesse écrasés. Il s'agit donc de fichiers à longue durée de vie dont le contenu est volatile et pas terriblement volumineux.
• En cas de doute, prévoir un moyen pour l'utilisateur de passer outre. Par exemple, le programme mktemp honore la variable d'environnement TMPDIR.

Édition pragmatique :

Utilisez /dev/shm quand il est important d'utiliser tmpfs, /var/tmp quand il est important de ne pas le faire, sinon /tmp.

Là où tmpfs excelle

fsync est un no-op sur tmpfs. Cet appel système est l'ennemi numéro un des performances (et de la longévité du flash, si vous vous en souciez), mais si vous utilisez tmpfs (ou eatmydata ) juste pour vaincre fsync, alors vous (ou un autre développeur de la chaîne) faites quelque chose de mal. Cela signifie que les transactions vers le périphérique de stockage sont inutilement délicates pour votre objectif - vous êtes clairement prêt à sauter certains points de sauvegarde pour des raisons de performance, car vous êtes maintenant allé jusqu'à les saboter tous - ce qui est rarement le meilleur compromis. C'est également dans le domaine des performances des transactions que l'on trouve les plus grands avantages d'un SSD : tout SSD décent aura des performances hors du commun par rapport à ce que peut supporter un disque tournant (7200 tr/min = 120 Hz, si personne d'autre n'y accède), sans parler des cartes mémoire flash, qui varient considérablement selon ce critère (notamment parce qu'il s'agit d'un compromis avec les performances séquentielles, qui sont évaluées en fonction de la classe de la carte SD, par exemple). Alors attention, développeurs avec des SSD ultra-rapides, de ne pas forcer vos utilisateurs dans ce cas d'utilisation !

Vous voulez entendre une histoire ridicule ? Ma première leçon fsync : mon travail consistait à “mettre à niveau” régulièrement un tas de bases de données Sqlite (conservées comme cas d'essai) vers un format actuel en constante évolution. Le cadre de “mise à niveau” exécutait un tas de scripts, effectuant au moins une transaction chacun, pour mettre à niveau une base de données. Bien sûr, j'ai mis à jour mes bases de données en parallèle (8 en parallèle, puisque j'ai eu la chance de disposer d'un puissant processeur à 8 cœurs). Mais comme je l'ai découvert, il n'y a eu aucune accélération de la parallélisation (plutôt une légère hit) parce que le processus était entièrement lié aux entrées-sorties. Hilarant, envelopper le cadre de mise à niveau dans un script qui copiait chaque base de données en /dev/shm, le mettait à niveau là, et le recopiait sur le disque était genre 100 fois plus rapide (toujours avec 8 en parallèle). En prime, le PC était également utilisable, tout en mettant à jour les bases de données.

Où tmpfs est approprié

L'utilisation appropriée de tmpfs est d'éviter l'écriture inutile de données volatiles. Désactiver efficacement le writeback, comme mettre /proc/sys/vm/dirty_writeback_centisecs à l'infini sur un système de fichiers normal.

Cela a très peu à voir avec les performances, et ne pas le faire est un problème bien moins important que d'abuser de fsync : Le délai de réécriture détermine la paresse avec laquelle le contenu du disque est mis à jour après le contenu du pagecache, et le délai de 5 secondes par défaut est long pour un ordinateur - une application peut écraser un fichier aussi souvent qu'elle le souhaite, dans le pagecache, mais le contenu du disque n'est mis à jour qu'environ toutes les 5 secondes. A moins que l'application ne le force avec fsync, c'est à dire. Pensez au nombre de fois qu'une application peut produire un petit fichier dans ce laps de temps, et vous verrez pourquoi la synchronisation par synchro serait un problème bien plus important.

Ce que tmpfs ne peut pas vous aider avec

• Performances de lecture. Si vos données sont chaudes (ce qui est préférable si vous envisagez de les conserver dans tmpfs), vous tomberez quand même sur le cache de la page. La différence se situe au niveau de l'affichage du cache ; si c'est le cas, allez à “Where tmpfs sux”, ci-dessous.
• Fichiers de courte durée. Ces fichiers peuvent vivre toute leur vie dans le cache (sous forme de vingt pages) avant même d'être écrits. A moins que vous ne le forciez avec fsync bien sûr.

Où tmpfs sux

Conserver des données froides. Vous pourriez être tenté de penser que servir des fichiers en dehors de l'espace de pagination est tout aussi efficace qu'un système de fichiers normal, mais il y a plusieurs raisons pour lesquelles ce n'est pas le cas :

• La raison la plus simple : Il n'y a rien que les périphériques de stockage contemporains (qu'ils soient basés sur un disque dur ou sur une mémoire flash) aiment plus que la lecture de fichiers assez séquentiels, organisés avec soin par un système de fichiers approprié. Il est peu probable que l'échange en blocs de 4KiB améliore cette situation.
• Le coût caché : L'échange de. Les pages Tmpfs sont dirty - elles doivent être écrites quelque part (à échanger) pour être expulsées du pagecache, par opposition aux pages nettoyées soutenues par des fichiers qui peuvent être supprimées instantanément. C'est une pénalité d'écriture supplémentaire sur tout ce qui est en compétition pour la mémoire - qui affecte autre chose à un moment différent de l'utilisation de ces pages tmpfs.

Bon, voici la réalité.

Les deux tmpfs et un système de fichiers normal sont un cache mémoire sur disque.

Le tmpfs utilise de la mémoire et de l'espace de swap comme mémoire de sauvegarde ; un système de fichiers utilise une zone spécifique du disque, aucun des deux n'est limité dans la taille que peut avoir le système de fichiers, il est tout à fait possible d'avoir un tmpfs de 200 Go sur une machine avec moins d'un Go de RAM si vous avez suffisamment d'espace de swap.

La différence réside dans le moment où les données sont écrites sur le disque. Pour un tmpfs, les données sont écrites UNIQUEMENT lorsque la mémoire est trop pleine ou que les données ne seront probablement pas utilisées prochainement. OTOH La plupart des systèmes de fichiers Linux normaux sont conçus pour avoir toujours un ensemble de données plus ou moins cohérent sur le disque, de sorte que si l'utilisateur débranche le système, il ne perd pas tout.

Personnellement, je suis habitué à avoir des systèmes d'exploitation qui ne plantent pas et des systèmes UPS (ex : batteries de portables) donc je pense que les systèmes de fichiers ext2/3 sont trop paranoïaques avec leur intervalle de contrôle de 5 à 10 secondes. Le système de fichiers ext4 est meilleur avec un point de contrôle de 10 minutes, sauf qu'il traite les données des utilisateurs comme des données de seconde classe et ne les protège pas. (ext3 est le même mais vous ne le remarquez pas à cause du point de contrôle de 5 secondes)

Ce contrôle fréquent signifie que des données inutiles sont continuellement écrites sur le disque, même pour /tmp.

Il en résulte que vous devez créer un espace d'échange aussi grand que votre /tmp doit l'être (même si vous devez créer un fichier d'échange) et utiliser cet espace pour monter un tmpfs de la taille requise sur /tmp.

N'utilisez JAMAIS /dev/shm.

Sauf si vous l'utilisez pour de très petits fichiers IPC (probablement mmap’d) et que vous êtes sûr qu'il existe (ce n'est pas un standard) et que la machine a plus que suffisamment de mémoire + swap disponible.

Utilisez /tmp/ pour les fichiers temporaires. Utilisez /dev/shm/ lorsque vous souhaitez une mémoire partagée (c'est-à-dire une communication interprocessus par le biais de fichiers).

Vous pouvez compter sur la présence de /tmp/, mais /dev/shm/ est une chose relativement récente sous Linux seulement.

Un autre moment où vous devriez utiliser /dev/shm (pour Linux 2.6 et plus) est lorsque vous avez besoin d'un système de fichiers tmpfs garanti parce que vous ne savez pas si vous pouvez écrire sur le disque.

Un système de surveillance que je connais bien a besoin d'écrire des fichiers temporaires tout en construisant son rapport pour le soumettre à un serveur central. En pratique, il est beaucoup plus probable que quelque chose empêche d'écrire sur un système de fichiers (soit par manque d'espace disque, soit par une défaillance sous-jacente du RAID qui a poussé le système en mode lecture seule), mais vous pourrez quand même boiter pour alerter à ce sujet que si quelque chose fait monter en flèche toute la mémoire disponible, de sorte que le tmpfs sera inutilisable (et la boîte ne sera pas morte). Dans de tels cas, un système de surveillance préférera écrire dans la mémoire vive afin de pouvoir éventuellement envoyer une alerte en cas de disque plein ou de matériel mort.

/dev/shm est utilisé pour les pilotes et programmes de périphériques spécifiques aux systèmes de mémoire virtuelle partagée.

Si vous créez un programme qui nécessite un tas de mémoire virtuelle qui doit être mappé en mémoire virtuelle. Cela vaut doublement si vous avez besoin de plusieurs processus ou threads pour pouvoir accéder à cette mémoire en toute sécurité.

Le fait est que ce n'est pas parce que le pilote utilise une version spéciale de tmpfs pour ce programme que vous devez l'utiliser comme une partition tmpfs générique. Au contraire, vous devez simplement créer une autre partition tmpfs si vous en voulez une pour votre répertoire temporaire.

Dans PERL, ayant 8 Go minimum sur n'importe quelle machine (toutes fonctionnant sous Linux Mint), je suis de ce que je pense être une bonne habitude de faire des algorithmes complexes basés sur DB_File (structure de données dans un fichier) avec des millions de lectures et d'écritures en utilisant /dev/shm

Dans d'autres langues, n'ayant pas gigether partout, pour éviter les démarrages et les arrêts dans le transfert réseau (travailler localement sur un fichier qui se trouve sur un serveur dans une atmosphère client-serveur), en utilisant un fichier batch d'un certain type, je vais copier tout le fichier (300-900MB) en une fois dans /dev/shm, exécuter le programme avec sortie dans /dev/shm, réécrire les résultats sur le serveur, et supprimer dans /dev/shm

Naturellement, si j'avais moins de RAM, je ne ferais pas cela. Normalement, le système de fichiers en mémoire de /dev/shm se lit comme une taille correspondant à la moitié de votre RAM disponible. Cependant, l'utilisation ordinaire de la RAM est constante. Vous ne pourriez donc pas vraiment faire cela sur un appareil de 2 Go ou moins. Pour transformer la paraphrase en hyperbole, il y a souvent des choses dans la RAM que même le système ne rapporte pas bien.