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

Dans l'ordre décroissant de tmpfs probabilité :

 /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 système spécifique à Linux tmpfs par rapport à un répertoire défini de manière portative qui mai soit tmpfs (en fonction de votre administrateur système et de ce qui est par défaut pour votre distro), votre question comporte deux aspects, sur lesquels les autres réponses ont insisté différemment :

1. Utilisation appropriée de divers répertoires tmp
2. Utilisation appropriée de tmpfs

Utilisation appropriée des différents répertoires tmp

_Basé sur l'ancien Standard de la hiérarchie des systèmes de fichiers et ce que Systemd dit à ce sujet ._

• En cas de doute, utilisez /tmp .
• Utilice /var/tmp pour les données qui doivent persister à travers les redémarrages.
• Utilice /var/tmp pour les données volumineuses qui peuvent difficilement tenir dans la RAM (en supposant que /var/tmp a plus d'espace disponible - généralement une hypothèse juste).
• Utilice /dev/shm seulement comme un effet secondaire de l'appel shm_open() . Le public visé est celui des tampons délimités qui sont écrasés sans cesse. C'est donc pour les fichiers à longue durée de vie dont le contenu est volatile et pas terriblement grand.
• N'utilisez surtout pas /dev/shm pour les exécutables (de n'importe quel type), car il est couramment monté noexec .
• Si le doute persiste, donnez à l'utilisateur la possibilité de passer outre. Pour le moins de surprise possible, faites comme mktemp et honorer le TMPDIR variable d'environnement.

Où tmpfs excelle

tmpfs Les performances sont trompeuses. Vous trouverez des charges de travail qui sont plus rapides sur tmpfs, et ceci est pas parce que la RAM est plus rapide que le disque : Tous les systèmes de fichiers sont mis en cache en RAM - le cache des pages ! C'est plutôt un signe que la charge de travail fait quelque chose qui met en échec le cache des pages. Et l'une des pires choses qu'un processus puisse faire à cet égard est de se synchroniser sur le disque bien plus souvent que nécessaire.

fsync est un no-op sur tmpfs. Cet appel système demande au système d'exploitation de vider son cache de pages pour un fichier, jusqu'à vider le cache d'écriture du périphérique de stockage concerné, tout en empêchant le programme qui l'a lancé de progresser - une barrière d'écriture très grossière. C'est un outil nécessaire dans la boîte uniquement parce que les protocoles de stockage ne sont pas conçus en fonction des transactions. Et la mise en cache est là en premier lieu pour permettre aux programmes d'effectuer des millions de petites écritures dans un fichier sans se rendre compte de la lenteur réelle de l'écriture sur un périphérique de stockage - toutes les écritures réelles se font de manière asynchrone, ou jusqu'à ce qu'elles soient exécutées. fsync est appelé, ce qui est le seul endroit où la performance d'écriture est directement ressentie par le programme.

Donc, si vous vous retrouvez à utiliser tmpfs (ou données sur l'alimentation ) juste pour battre fsync, alors vous (ou un autre développeur dans la chaîne) faites quelque chose de mal. Cela signifie que les transactions vers le périphérique de stockage sont inutilement fines pour votre objectif - vous êtes clairement prêt à sauter certains points de sauvegarde pour la performance, puisque vous êtes maintenant allé jusqu'à les saboter tous - rarement le meilleur compromis. De plus, c'est ici, au pays des performances de transaction, que se trouvent certains des plus grands avantages d'un SSD - tout SSD digne de ce nom aura des performances hors du commun par rapport à ce qu'un disque rotatif peut supporter (7200 tr/min = 120 Hz, si rien d'autre n'y accède). Les cartes mémoire flash varient également beaucoup sur cette mesure (il s'agit d'un compromis avec les performances séquentielles, et la classification des cartes SD ne prend en compte que ces dernières). Alors attention, développeurs de SSD ultra-rapides, ne forcez pas vos utilisateurs dans ce cas d'utilisation !

Vous voulez entendre une histoire ridicule ? Ma première fsync leçon : J'ai eu un travail qui impliquait la "mise à niveau" régulière d'un ensemble de bases de données Sqlite (conservées comme cas de test) vers un format actuel en constante évolution. Le framework de "mise à jour" exécutait un tas de scripts, faisant au moins une transaction chacun, pour mettre à jour une base de données. Bien sûr, je mettais à jour mes bases de données en parallèle (8 en parallèle, puisque j'avais la chance d'avoir un puissant CPU à 8 cœurs). Mais comme je l'ai découvert, il n'y a pas eu d'accélération de la parallélisation (plutôt une légère augmentation de la vitesse). touchez ) parce que le processus était entièrement lié à l'IO. De façon hilarante, en enveloppant le cadre de mise à niveau dans un script qui copiait chaque base de données vers /dev/shm La mise à jour et la copie sur disque étaient 100 fois plus rapides (toujours avec 8 en parallèle). En prime, le PC était utilisable également, lors de la mise à jour des bases de données.

Où tmpfs est approprié

L'utilisation appropriée de tmpfs est d'éviter l'écriture inutile de données volatiles. La désactivation effective de reprise d'écriture comme le réglage /proc/sys/vm/dirty_writeback_centisecs à l'infini sur un système de fichiers ordinaire.

Cela n'a pas grand-chose à voir avec les performances, et l'échec de cette opération est une préoccupation bien moins importante que l'abus 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 la valeur par défaut de 5 secondes est une longue période 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'une fois toutes les 5 secondes environ. À moins que l'application ne force la mise à jour avec fsync, bien sûr. Pensez au nombre de fois qu'une application peut sortir un petit fichier dans ce laps de temps, et vous comprenez pourquoi la fsynchronisation de chaque fichier serait un problème bien plus important.

Ce pour quoi tmpfs ne peut pas vous aider

• Lire la performance. Si vos données sont chaudes (et elles ont intérêt à l'être si vous envisagez de les conserver dans tmpfs), vous utiliserez le cache de page de toute façon. La différence se situe au niveau de la non-utilisation du cache de la page ; si c'est le cas, allez à "Là où tmpfs sux", ci-dessous.
• Des dossiers de courte durée. Ils peuvent vivre toute leur vie dans le pagecache (comme sale pages) avant même d'être écrites. A moins que vous ne le forciez avec fsync bien sûr.

Où tmpfs sux

En gardant froid données. Vous pourriez être tenté de penser que servir des fichiers à partir de l'espace d'échange 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 dispositifs de stockage contemporains (qu'il s'agisse d'un disque dur ou d'une mémoire flash) n'aiment plus que la lecture de fichiers assez séquentiels organisés de manière ordonnée par un système de fichiers approprié. Il est peu probable que l'échange de blocs de 4KiB améliore cette situation.
• Le coût caché : Changer le site out . Les pages Tmpfs sont sale - ils doivent être écrits quelque part (dans le swap) pour être expulsés du pagecache, par opposition aux fichiers sauvegardés. nettoyer des pages qui peuvent être abandonnées instantanément. C'est une pénalité d'écriture supplémentaire sur tout ce qui est en compétition pour la mémoire - cela affecte quelque chose d'autre à un moment différent que l'utilisation de ces pages tmpfs.

Ok, voilà la réalité.

Tant tmpfs qu'un système de fichiers normal sont un cache mémoire sur disque.

Le tmpfs utilise la mémoire et l'espace d'échange (swapspace) comme mémoire de sauvegarde ; un système de fichiers utilise une zone spécifique du disque, ni l'un ni l'autre n'est limité dans la taille du 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 d'échange.

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 lorsque les données ne seront probablement pas utilisées bientôt. En revanche, la plupart des systèmes de fichiers Linux normaux sont conçus pour avoir toujours un ensemble plus ou moins cohérent de données sur le disque, de sorte que si l'utilisateur débranche la prise, il ne perde pas tout.

Personnellement, j'ai l'habitude d'avoir des systèmes d'exploitation qui ne se plantent pas et des systèmes UPS (ex : batteries d'ordinateurs portables) donc je pense que les systèmes de fichiers ext2/3 sont trop paranoïaques avec leur intervalle de point 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 de l'utilisateur comme une seconde classe et ne les protège pas. (ext3 est le même mais vous ne le remarquez pas à cause du checkpoint de 5 secondes)

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

Le résultat est que vous devez créer un espace d'échange aussi grand que votre /tmp (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.

À moins que vous ne l'utilisiez pour de très petits fichiers IPC (probablement mmapés), que vous soyez sûr qu'il existe (ce n'est pas un standard) et que la machine dispose de plus de mémoire + swap que nécessaire.

Utilisez /tmp/ pour les fichiers temporaires. Utilisez /dev/shm/ lorsque vous voulez de la mémoire partagée (c'est-à-dire la communication interprocessus à travers des fichiers).

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

Une autre occasion 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 peut écrire sur le disque.

Un système de surveillance que je connais bien doit écrire des fichiers temporaires pendant qu'il construit son rapport pour le soumettre à un serveur central. En pratique, il est beaucoup plus probable que quelque chose empêche l'écriture dans un système de fichiers (soit par manque d'espace disque, soit parce qu'une défaillance du RAID sous-jacent a poussé le système dans un mode de lecture seule) mais que vous puissiez quand même avancer sans être alerté que si quelque chose détruit toute la mémoire disponible de sorte que tmpfs soit inutilisable (et que la machine ne soit pas morte). Dans des cas comme celui-ci, un système de surveillance préférera écrire en RAM afin d'être potentiellement capable d'envoyer une alerte sur un disque plein ou un matériel mort ou mourant.