我的 VPS 主机的配置 Web 界面为我提供了一个下拉框来设置我的/tmp.
默认为“16MB RAM”，替代选项为“硬盘”。
只有 16MB 的/tmp可用空间是否可能会给某些软件带来麻烦？或不？
答案1
只有 16MB 可用的 /tmp 是否可能会给某些软件带来麻烦？
是的，如果某个软件想要写入/tmp并且它或其他软件已经填充了分区。一般来说，这可能表明系统配置不佳、对可用资源的合法限制，或者其他软件的行为不当——无论如何，想要编写的软件不太可能尝试自行找到解决方案并会抛出错误。
有些软件会假设它可以将大文件写入/tmp，公平地说，这是一个公平的假设。这个问题属于“配置不当”的错误范畴。
您应该问自己的第一个问题是：“使用 RAM 对我来说有什么好处/tmp？”最明显的是潜在的好处是访问 RAM 比访问磁盘快得多。然而，这种明显的潜在好处在现实中不太可能有那么大的好处，因为：
无论如何，系统都会将经常访问的文件缓存在 RAM 中。减少可用于此缓存的 RAM 量以便将
/tmp其放入其中有点愚蠢，因为这意味着不常用的文件/tmp将取代缓存中的常用文件。应用程序已经可以自由地将内容存储在 RAM 中，这通常比将它们存储在文件中更容易，因此如果它们将某些内容放入 tmp 文件中，则不太可能会从 RAM 中受益。如果您查看 中的实际内容
/tmp，可能主要是套接字和 fifo 或少量 IPC 数据。通过基于 RAM 的文件系统访问它们在概念上更简洁，但我怀疑这会产生任何真正的区别。
既然如此，为什么还要/tmp在RAM中实现呢？
它简化了 的首选属性的实现
/tmp，即它在关闭时被擦除。它可能会稍微减少硬件的磨损。这在仅具有廉价的、有限寿命的闪存用于存储或根本没有可写存储（例如嵌入式系统）的环境中更为重要。
假设
/tmp没有被滥用，使用 RAM 会利用现代硬件通常巨大的内存容量——也就是说，这些东西也可能在 RAM 中，假设它是它应该是的那种东西。
16MB可以已经足够了，但如果某个进程失控，也还不算什么——而且/tmp必须是任何人都可写的。然而，如果某个进程在向 写入内容时出现混乱/tmp，如果它最终填满硬盘，或者因为耗尽了 RAM 分区而更快地发出红旗，会更好吗？
如果你对你正在使用的软件有信心，后者更有意义，所以你可以选择 RAM 分区。您应该首先检查一下您的实际/tmp使用情况，以防发生任何异常情况（例如du -h /tmp）。您可以提出一个“正常阈值”，并使用 cron 作业检查该阈值，以在超出阈值时向某人发出警报和/或进行一些紧急清理。
不幸的是，某些应用程序可能偶尔会转储一些内容，/tmp如果突然失败，这些内容不会被删除，而在服务器上（不会经常关闭），这些内容可能会无限期地留在那里。我认为，这种情况的发生可能是非常无害的，例如，当有人登录并使用某些东西时，连接就会被任意关闭或放弃。
所以非RAM/tmp更安全。滥用行为可能会在更长时间内不被注意到，但这只是因为它不像 RAM 那样严重。此外，如果某些事情确实引起了问题，磁盘上就会留下确凿的证据，指出问题的根源。