何时使用/dev/shm/？何时使用/tmp/？我能否始终依赖它们同时存在于 UNIX 上？
答案1
/dev/shm是临时文件存储文件系统，即临时文件，使用 RAM 作为后备存储。它可以用作共享内存实现，以促进工业控制计算机。
最近的 2.6 Linux 内核版本已经开始以 ramdisk 的形式提供 /dev/shm 作为共享内存，更具体地说，是作为存储在内存中的、在 /etc/default/tmpfs 中具有定义限制的全球可写目录。 /dev/shm 支持在内核配置文件中完全是可选的。 它默认包含在 Fedora 和 Ubuntu 发行版中，其中 Pulseaudio 应用程序最广泛地使用它。 （重点已添加。）
/tmp是临时文件的位置，定义在文件系统层次标准，几乎所有的 Unix 和 Linux 发行版都遵循这一标准。
由于 RAM 比磁盘存储快得多，您可以使用/dev/shm而不是/tmp提高性能，如果您的进程是 I/O 密集型的并且大量使用临时文件。
回答你的问题：不，你不能总是依赖于/dev/shm在场，当然不能依赖于内存不足的机器。/tmp除非你有非常好的理由使用，否则你应该使用/dev/shm。
请记住，/tmp可以是文件系统的一部分/，而不是单独挂载，因此可以根据需要增长。的大小/dev/shm受系统上多余的 RAM 限制，因此您更有可能用尽此文件系统上的空间。
答案2
您实际上不应该直接使用/dev/shm，但如果使用tmpfs文件系统特别有益，您可以这样做。因此，除了回答各种临时目录的用途外，我还将回答您真正想问的问题：我应该何时使用tmpfs？
| 临时目录 | 多么短暂 | 可移植性 | 有可能的使用 |
|---|---|---|---|
| /dev/shm | 总是 tmpfs | Linux 特定 | 永远不要（至少直接不要）。使用shm_open()。此目录用于共享内存进程间通信，而不是临时文件。 |
| /tmp | 可以是 tmpfs | 高速 1.0 | 如有疑问，请使用"${TMPDIR:-/tmp}" |
| /var/tmp | 永不 tmpfs | 高速 1.0 | 由于文件太大或寿命太长而无法放入 /tmp |
各种临时目录的用途
基于古代文件系统层次标准还有什么Systemd 就此事表示。
- 如有疑问，请使用
/tmp。 - 用于
/var/tmp在重启后仍需保留的数据。 - 用于
/var/tmp可能无法轻易放入 RAM 中的大数据（假设/var/tmp有更多可用空间 -通常一个合理的假设）。 /dev/shm仅作为调用 的副作用使用shm_open()。目标受众是被无限覆盖的有界缓冲区。因此，这适用于内容不稳定且不是特别大的长期文件。- 绝对不要用于
/dev/shm可执行文件（任何类型），因为它通常被安装noexec。 - 如果仍有疑问，请为用户提供一种覆盖方法。为了尽量减少意外，请喜欢
mktemp并尊重TMPDIR环境变量。
tmpfs 的优势
tmpfs性能是骗人的。你会发现在 tmpfs 上工作负载更快，这是不是因为 RAM 比磁盘快：所有文件系统都缓存在 RAM 中 - 页面缓存！相反，这表明工作负载正在做一些破坏页面缓存的事情。在这方面，进程可能做的最糟糕的事情是比必要的更频繁地同步到磁盘。
fsync在 tmpfs 上是无操作。此系统调用告诉操作系统刷新文件的页面缓存，一直刷新相关存储设备的写入缓存，同时阻止发出此调用的程序取得任何进展 - 这是一个非常粗糙的写入屏障。它只是盒子里的一个必需工具，因为存储协议不是为事务而设计的。缓存的存在首先是为了使程序能够对文件执行数百万次小写入，而不会注意到写入存储设备的速度实际上有多慢 - 所有实际写入都是异步发生的，或者直到fsync被调用，这是程序直接感受到写入性能的唯一地方。
因此，如果你发现自己正在使用 tmpfs（或吃我的数据) 只是为了击败 fsync，那么您（或链中的其他开发人员）就做错了。这意味着针对存储设备的事务不必要地细粒度化了您的目的——您显然愿意跳过一些保存点以提高性能，因为您现在已经走到了破坏所有保存点的极端——这很少是最好的妥协。此外，在事务性能领域，拥有 SSD 的一些最大好处是——任何有价值的 SSD 都将比旋转磁盘所能承受的（7200 rpm = 120 Hz，如果没有其他内容访问它）表现出色。闪存卡在这个指标上也有很大差异（这是与顺序性能的权衡，SD 卡等级评定只考虑后者）。所以要小心，拥有超快 SSD 的开发人员，不要强迫您的用户使用这种用例！
想听一个荒谬的故事吗？我的第一个fsync教训：我的工作是定期将一堆 Sqlite 数据库（作为测试用例保存）“升级”为不断变化的当前格式。“升级”框架将运行一堆脚本，每个脚本至少进行一次事务，以升级一个数据库。当然，我并行升级了我的数据库（并行升级了 8 个数据库，因为我有强大的 8 核 CPU）。但我发现，并行化速度根本没有提高（反而略有提高）打)，因为该过程完全受 IO 限制。有趣的是，将升级框架包装在一个脚本中，该脚本将每个数据库复制到/dev/shm，在那里升级，然后将其复制回磁盘，速度快了 100 倍（仍然并行 8 个）。作为奖励，PC可用的在升级数据库时也是如此。
tmpfs 适用的情况
tmpfs 的正确使用是为了避免不必要地写入易失性数据。有效地禁用写回，就像/proc/sys/vm/dirty_writeback_centisecs在常规文件系统上设置为无穷大一样。
这与性能关系不大，而且与滥用 fsync 相比，失败的担忧要小得多：写回超时决定了页面缓存内容之后磁盘内容更新的速度有多慢，默认的 5 秒对于计算机来说是很长的时间——应用程序可以在页面缓存中随意覆盖文件，但磁盘上的内容每 5 秒仅更新一次。除非应用程序强制使用 fsync。想想应用程序在这段时间内可以输出一个小文件多少次，你就会明白为什么对每个文件都进行 fsync 会是一个更大的问题。
tmpfs 无法帮到您的问题
- 读取性能。如果您的数据很热（如果您考虑将其保存在 tmpfs 中，情况会更好），无论如何您都会访问页面缓存。区别在于不访问页面缓存的情况；如果是这种情况，请转到下面的“tmpfs 在哪里很糟糕”。
- 短寿命文件。这些文件可以一直存在于页面缓存中（因为肮脏的页）才会被写出来。除非你用
fsync“当然”来强迫它。
tmpfs 糟糕之处
保持寒冷的数据。您可能会认为，通过交换提供文件与普通文件系统一样高效，但有两个原因导致事实并非如此：
- 最简单的原因：当代存储设备（无论是硬盘还是闪存）最喜欢读取由适当文件系统整齐组织的相当连续的文件。以 4KiB 块进行交换不太可能改善这一点。
- 隐性成本：交换出去. Tmpfs 页面是肮脏的— 它们需要被写入某个地方（进行交换）以便从页面缓存中清除，而不是文件备份干净的可以立即删除的页面。这是对其他所有争用内存的事物的额外写入惩罚 – 与使用这些 tmpfs 页面不同，它会影响其他事物。
答案3
好吧，现实情况就是这样。
tmpfs 和普通文件系统都是磁盘上的内存缓存。
tmpfs 使用内存和交换空间作为它的后备存储，文件系统使用磁盘的特定区域，文件系统的大小不受限制，如果有足够的交换空间，在内存不足 1 GB 的机器上完全可以拥有 200GB 的 tmpfs。
不同之处在于数据写入磁盘的时间。对于 tmpfs，仅当内存太满或数据不太可能很快使用时才会写入数据。另一方面，大多数普通 Linux 文件系统都设计为在磁盘上始终具有或多或少一致的数据集，因此如果用户拔掉电源插头，他们不会丢失所有内容。
就我个人而言，我习惯使用不会崩溃的操作系统和 UPS 系统（例如：笔记本电脑电池），因此我认为 ext2/3 文件系统对其 5-10 秒的检查点间隔过于偏执。ext4 文件系统具有 10 分钟的检查点，效果更好，但它将用户数据视为二等数据并且不对其进行保护。（ext3 也一样，但由于 5 秒的检查点，您不会注意到它）
这种频繁的检查点意味着不必要的数据被不断地写入磁盘，即使对于 /tmp 也是如此。
因此结果是您需要创建与 /tmp 所需的一样大的交换空间（即使您必须创建交换文件）并使用该空间将所需大小的 tmpfs 安装到 /tmp 上。
永远不要使用 /dev/shm。
除非您将它用于非常小的（可能是 mmap'd）IPC 文件，并且您确定它存在（它不是标准）并且机器有足够的内存 + 可用交换。
答案4
另一个你应该使用 /dev/shm（适用于 Linux 2.6 及以上版本）的情况是当你需要一个有保障的 tmpfs 文件系统时，因为你不知道你是否能写入磁盘。
我熟悉的监控系统需要在构建报告以提交给中央服务器时写出临时文件。在实践中，更有可能的是某些东西会阻止写入文件系统（磁盘空间不足或底层 RAID 故障导致系统进入硬件只读模式），但您仍然可以勉强发出警报，而不是某些东西耗尽所有可用内存，导致 tmpfs 无法使用（并且盒子不会死机）。在这种情况下，监控系统将优先写入 RAM，以便能够发送有关磁盘已满或硬件死机/即将死机的警报。