【外评】茶壶中的 Debian /tmpest

共有 117 条讨论

1. 终于完成了！现在要检查的是，这些改动是否真的破坏了我已经切换到 tmpfs 的系统…

   回复

   1. 只要你在 /etc 中添加了 tmp.mount，或在 fstab 中添加了条目，就不会有问题了

      回复

      1. 我是老派人，所以要在 fstab 中加入条目。感谢您的回复！

         回复

2. 我在 Debian 上使用 tmpfs /tmp，因为它已被添加到内核中，没有任何问题。

   不过，我不会自动清理它。如果需要，tmpfs 会被换到磁盘上。

   如果启用了清理功能，它应该有一个大小阈值，不清理小于几千字节的文件。在内存容量高达数十 GB 的今天，删除这些文件对任何人都没有实际帮助。

   回复

3. 我很惊讶他们没有谈到内存使用情况

   我遇到过很多次使用 /tmp 来存储临时文件的情况，因为这些文件太大，无法保存在内存中：rootfs 很可能大于 10GB，而内存则更为稀缺（虽然我们可以在磁盘上保存此类文件一段时间，但使用内存的成本要比使用磁盘高）。

   没有什么太难处理的，我想这些用户都能应对相应的变化

   回复

   1. 内存中的 /tmp 会在内存紧张时被换出。因此，大文件对内存的占用都是暂时的。

      与直接写入磁盘相比，交换可能会增加一些开销，但不再写入磁盘的所有小文件应该足以抵消这些开销。

      回复

      1. 是的

         在高性能计算环境中，交换真的是一种好做法吗？

         回复

         1. 绝对是！如果你正在处理大量数据，几乎可以保证至少有一部分数据会比内存中的其他数据更热。因此，将更多内存用于页面缓存等用途，有利于充分利用内存。

            回复

         2. 令人惊讶的是，是的。不是以前的 2 倍内存准则，但一些交换可以释放内存。

            回复

            1. 同意。即使在我的 128GB 内存服务器上，通常也只使用几十 MB 的交换空间。

               回复

         3. 无论虚拟内存的大小或类型如何，内核对虚拟内存的布局都有一定的假设。30 多年来，x86 系统一直假设磁盘区域可根据需要用于额外的内存，而不管内存是否被使用。当内存耗尽时，坏事就会发生。比如，无法恢复，有时甚至无法诊断。

            我不记得 Linux 内核是否会将其核心转储到 /var/crash 中，还是默认情况下会使用交换空间区域。我已经很久没有看到内核彻底崩溃了，我都忘了它会把发生故障的东西放在哪里。

            回复

            1. 另一方面，交换不会改变任何事情：你仍然可以让内存空间达到饱和，只是需要更长的时间，在此期间你的系统会瘫痪

               回复

         4. 是的，交换几乎总是一个好主意，因为它允许匿名内存在内存压力下被交换出去。如果没有交换功能，就会减少可被交换的内存池（即只有可执行文件、库等已编译的内存，以及各种内核缓存，如 dentries/inodes）。可交换的内存池越小，通常就意味着需要更频繁地交换内存，因为你不能只交换最不常用的内存。因此，如果没有交换，内存压力就会增加，对 IO 及其延迟的依赖性也会增加。

            因此，增加交换。在大多数情况下，它能让速度更快。

            回复

            1. 在我的系统中，我一直倾向于避免交换，因为如果有东西乱用了太多内存，我不希望内核在最终放弃并杀死它或分配失败之前，花上一分钟的时间来交换东西，为它腾出空间。我**希望内核能够交换掉它不会使用的东西，但我更希望能够说 “只主动交换，如果有内存压力，就启动 OOM 杀手”。

               回复

               1. earlyoom/(systemd-)oomd （选择你喜欢的类型，我相信现在还有更多类型）正是如此。我一直在等着有人提起它，但在我看来，它绝对是任何现代 Linux 桌面上都必须安装的东西。

                  回复

                  1. 我想说的是，earlyoom 在技术上并不那么严格，而且请注意，除非你至少配置了合理数量的交换机，否则任何基于 PSI 指标的方法都无法正常工作。否则，几乎任何内存峰值都会导致足够的压力来触发 oom kill。(如果你使用的是 ubuntu 等操作系统，而且最近经常出现应用程序随机消失的情况，这可能就是原因所在）

                     回复

               2. 在使用现代固态硬盘的电脑上，交换速度很快，而且不再对固态硬盘的寿命产生不良影响。在持续读写速度达到几 GB/s 的情况下，最坏的情况是性能逐渐下降，而不是停顿几秒钟。

                  如果固态硬盘较老，系统使用磁盘，或固态硬盘较新，但必须使用 LUKS 等软件加密，则应使用 zram 等压缩内存。当系统内存耗尽时，它还会带来性能逐渐下降的好处。

                  回复

                  1. 有些服务器所有者贪图便宜，使用 SATADOM 硬盘（速度真的很慢，只有 25 MB/s，而且是低端闪存盘，SATA 接口略微不标准）作为操作系统磁盘。在它们上面放置交换文件或分区是个非常糟糕的主意。

                     回复

               3. 我在一个拥有 64GB 内存的系统上，用 1GB swap 和 systemd-oomd 的组合得到了这样的结果。这样的交换容量刚刚好，在内存压力下，我不会立即开始交换可执行页面，而是优先交换使用频率较低的数据，但也不会交换得太多，以至于我崩溃。这样一来，systemd-oomd 就有足够的空间来干掉真正的内存大户，而不是不公平的受害者。

                  回复

         5. 我不了解高性能计算环境，但我个人过去 20 年在台式机/笔记本电脑上交换内存的经验是，一旦 Linux 因为某个进程（通常是 Chrome 浏览器或我正在编写的 C 代码）占用了太多内存而开始交换内存，我可能最好还是按下电源按钮，因为重启比等待系统从所有这些乱流中恢复要快得多。我以为固态硬盘能解决这个问题，但可惜没有。在上世纪 90 年代，当 486 机器只有几 MB 内存，交换不可避免时，情况还没这么糟。

            回复

            1. 造成交换的原因有很多。

               你所描述的是极端的内存压力，因为有一些进程失控，或者一些进程完全超出了可用硬件资源的负荷。

               你说得对，在这种情况下，交换几乎帮不上什么忙。

               不过，交换也用于释放内存中（可能）完全未使用的页面，并将空闲内存用于其他可提高性能的用途（如磁盘缓存）。

               内存中未使用的页面只会减少可用内存的数量。

               或者，它也可以用来清除内存中从未使用过的 tmpfs 文件。

               这些都是在后台进行的，与运行失控或过载情况无关。

               目前，由于交换的存在，我已经释放了约 1% 的内存用于执行有用的任务。虽然不多，但总比没有强。

               回复

               1. 在我了解到 “缺失的一环”（missing link）之前，我从未真正理解过拥有 swap 的紧迫性：可执行代码以命名页的形式映射到内存中。页面缓存没有内存，就意味着你的机器在读取当前运行进程的代码时，磁盘 I/O 会达到饱和状态。

                  回复

         6. 在大多数高性能计算设置中，交换是必不可少的；在单个系统中，你可以安装比 DDR 多一个 SI 单位数量级的 NVMe，而且两者的峰值带宽基本持平（Zen4 Epyc = 768GB/s DDR5 + 512GB/s×socket PCIe5），因此你可以以内存跟得上的速度进行交换。

            在一般情况下，禁用交换子系统并不会让速度更快–你只是失去了一个 “L5 “缓存层，内核在管理内存压力时可使用的动词也更少。(顺便提一句，DAMON/DAMOS 的全部意义在于让内核更有效地使用这些动词。它的目的是实现 NUMA 热/冷平衡，但它与交换之间的区别在很大程度上正变得学术化，如果几年后在桌面发行版上看到它的应用，我也不会感到惊讶）。

            回复

         7. 这确实取决于您的高性能计算环境。全集群 “超级计算机 “通常没有节点本地存储，因此没有交换。但这是另一回事–它们根本没有本地存储。

            回复

         8. 是的，这就是为什么 Kubernetes 对交换的敌意让我相当抓狂。

            回复

            1. 你错过了 https://kubernetes.io/blog/2021/08/09/run-nodes-with-swap… ？

               回复

      2. tmpfs 挂载往往有大小限制（默认值大概是内存的 50%吧？）

         试图将大文件下载到 /tmp 的程序可能会有一点风险，那就是最终会完全填满 /tmp 并导致失败。

         回复

         1. 总比填满根分区要好，因为根分区可能也不够大。

            在我看来，对于 RAM+swap 来说，你*知道*太大的大型临时文件属于 /var/tmp。

            回复

            1. > 在我看来，对于 RAM+swap 来说**知道**太大的大型临时文件属于 /var/tmp。

               这不是 /var/tmp 的用途 …

               只要重新定义/tmp的大小就可以了。在运行 gentoo 时，我把很多编译临时目录都移到了 /tmp，因为我总是使用大量的交换空间，所以我想我把 /tmp 定义为内存的三到四倍。如果编译 Firefox、loffice 或 gcc 等程序将我的机器拖入交换区，那就太意外了。

               但作为其中的一部分，我在 FHS 中找到了 /tmp 和 /var/tmp 的定义，并发现我把 /var/tmp 也变成了 tmpfs 是个大错误……

               /tmp 被定义为 “任何可能随时消失的东西”，所以重启后无法存活完全符合规范。

               另一方面，/var/tmp 则是 “不需要长期使用，但必须在重启或崩溃时存活 “的文件。我不记得确切的定义，但它显然是用于恢复信息，或本应被应用程序删除但由于崩溃而往往没有删除的工作集，等等等等。这些东西很可能会成为 “孤儿”，而你又不想让它们占用永久存储空间。

               干杯

               沃尔

               回复

               1. > 运行 gentoo

                  > 把 /var/tmp 也变成 tmpfs 是个大错误

                  给发现这篇文章的新 gentoo 用户：/var/tmp/portage 是 Gentoo 失败构建的坟墓。

                  针对该目录设置某种自动清理程序。

                  回复

      3. 交换，让软件运行得更快。

         我相信在很多情况下都会适得其反。

         回复

         1. 我注意到了你的假设，但除了 “内存压力太大，系统正在疯狂交换”（这意味着如果没有交换，OOM 杀手反而会触发；这两种情况你都不希望发生）或”/usr 位于快速固态硬盘上，但你的交换分区位于旋转铁锈上 “之外，我想不出其他情况。

            回复

   2. > 我很惊讶他们竟然没有谈到内存使用情况

      这在很大程度上是有意为之的，因为这种 “老鼠拖木锨 “的做法正是以前失败的原因。每一个关于为什么这不是问题的轶事，都会有一个来自别人的相反例子。这个默认设置可以进行微不足道的自定义，包括完全禁用或设置最大文件系统限制，以及无数其他组合。如果开箱即用，那就再好不过了；如果不行，那就按需定制。

      回复

      1. 我同意，在 RAMFS 上安装 /tmp 可能是个坏主意，但也有同样多的理由说明它是个好主意（轶事也是如此）。我有点同意文章标题的说法：这是茶壶里的风暴。如果使用情况不允许使用默认设置，那么这种特殊配置是很容易更改的，甚至不需要重启。如果你需要部署整个机群，在创建部署映像之前，可以使用一些工具来管理配置。

         回复

         1. 没错，管理整个机群对/etc/中的小配置文件的更改早已成为一个难题，而且有几十种解决方案随时可用

            回复

   3. 虽然在 FHS 中没有明确说明（但也许在其他地方），但通常使用 /var/tmp 保存大文件会更好。它在重启时会被保留，所以可能不是 tmpfs。

      https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15….

      回复

4. 2000 年，我即将出国留学，我知道宿舍里不能上网。我决定递归 wget 一些网络漫画，比如《User Friendly》，然后把它们刻录成光盘，这样我就有东西可以打发时间了。我认为 /tmp 是下载大量文件并制作 ISO 映像进行刻录的理想中转站，于是让 wget 运行了一夜。

   早上，我发现了一系列有趣的事实：（1）wget 根据 Last-Modified 头设置 mtime；（2）我的系统每天都有一个 cron 脚本删除 /tmp 中的旧文件；（3）由于（1）和（2）的结果，我的网络漫画存档只剩下一些最新的文件。

   那天，我学到了一课。(另外，我还设法重新下载了我需要的文件，并在航班起飞前刻录了光盘）。

   回复

   1. (4) 你应该发布错误报告，如果脚本也检查了 ctime 和 atime，就不会发生这种情况了。

      回复

5. Debian 仍然支持一些可用内存非常少的系统。我有一些运行 Debian 的 arm 系统，可用内存只有 64MB 或 128MB。因此，有必要在安装过程中轻松覆盖这一更改，以防止在安装过程中出现 OOM！

   回复

   1. 为什么需要这样做？在一个闲置的、刚安装的最小系统上只有几十个字节

      回复

      1. 在 64Mb 的系统上，几十*MB*是相当庞大的。我也处理过嵌入式系统，但做梦也不会想到要把 Debian 压缩到 64MB 的电路板上。

         apt 肯定会崩溃吧？

         回复

         1. 不是兆，是字节。为什么在一个空的、刚安装的系统中，/tmp/里会有几十兆字节？我刚启动了一个刚安装的 x86_64 Trixie 虚拟机，发现 /tmp/ 目录中有 8 个空目录，除此之外什么也没有。

            回复

   2. 我很感兴趣。你在这些 arm 系统上运行的是哪个版本的 Debian？trixie 安装程序是否支持这种内存容量的系统？

      回复

      1. 请参阅 https://forum.doozan.com/list.php?2 了解不同基于 Marvell SOC 的设备对 Debian 的支持情况，这些设备包括许多 NAS 服务器，其中一些只有 64MB 或 128MB 内存。

         回复

         1. 如果磁盘容量太小，您绝对不应该用它来存储大型临时文件，因为这会很快耗尽闪存。

            回复

6. 在我的一台机器上，我忘了禁用这个功能。

   所以我的编译当然失败了，因为我现在非常小的 /tmp 上的 7GB 空间都被依赖项占满了。

   这似乎是安装 Debian 机器时必须要做的一件事。就像在 vim 中禁用鼠标一样。

   回复

   1. 嗯……什么 “编译 “需要 7GB？还认为 `/tmp` 是个好地方？Debian（及其衍生系统）似乎是唯一还在使用非 tmpfs 的系统，所以这闻起来像是 Debian 特有的（或者至少是-focused）工具？也许是构建 Snaps？或者，其他发行版为避免这一问题所做的工作也可以适用于 Debian？

      回复

      1. 大型 C++ 项目的每个编译线程可以轻松占用 GB 或更多。我没有深入研究过在不使用 -pipe 的情况下，有多少数据会进入磁盘。但我看到过 GCC 将一些工作数据放到 /tmp 中

         回复

         1. 如果有人属于那 0.x% 的情况，在没有任何控制的情况下经常有 GB 的数据被写入 /tmp/，他们只需对系统进行相应的配置即可。Debian 安装程序不会自行编译数 GB 的 C++ 中间数据到 /tmp/，如果发生这种情况，那也是用户驱动的。

            回复

            1. > 0.x% 的案例

               [需要引用]

               正如我在另一条评论中所说，下载一个 .iso 文件就足以让我的整个会话夭折。

               我不认为 “下载一个文件，然后把它dd到USB设备上，从此不再使用 “在Linux用户中是一件罕见的事。

               回复

               1. 这就是为什么你的主页会有一个 “下载 “目录，默认情况下浏览器会使用该目录。要求默认设置适应你将 ISO 下载到 /tmp 的特定使用情况是完全荒谬的。只需根据自己的需要配置系统即可，这并不难。

                  回复

                  1. > 这就是为什么你的主页会有一个下载目录

                     下载目录不会被自动清理，这也是我在这种情况下没有使用它的原因。

                     > 要求默认设置适应你下载 ISO 到 /tmp 的特定使用情况，这完全是荒谬的。

                     在我看来，你心目中的用例是 “不要在 /tmp 中写入任何东西”。你有什么证据能证明这是正常的使用情况，而我确实是全世界唯一一个使用它的人吗？

                     那为什么不完全删除 /tmp？

                     回复

                     1. > 这不是自动清除的，所以我在这种情况下没有使用它。

                        如果你想要这样，可以在你的主目录中设置一个 tmpfiles.d，对其进行清理。或者使用 /var/tmp。可能性无穷无尽。

                        > 在我看来，你心中的用例是 “不要在 /tmp 中写入任何内容”。

                        不，这是你编造出来的稻草人。

                        回复

                        1. > 如果你想要这样，可以在你的主页上设置一个 tmpfiles.d，对其进行清理。或者使用 /var/tmp。可能性无穷无尽。

                           网上的（错误）信息也是如此。

                           你忘了，很多人只是想使用他们的电脑。要想找到关于 tmpfiles.d 的信息，就必须在信息不全的博客和垃圾文档中寻找。

                           我只知道管理我的个人家庭服务器所需要做的最低限度的事情。运行 gentoo 的原因之一是我个人的选择，这意味着我需要比大多数人知道得更多。但在查找我需要的信息时，通常会遇到这样的情况：搜索词找不到我要找的东西；搜索引擎认为自己比我更了解我要找的东西，所以忽略了关键词语；正如我所说的，信息不全的博客；没有读懂问题的答案，等等等等。

                           可能性无穷无尽，但并不意味着凡人也能找到它们–它们往往在无限不可能的搜索引擎中消失了……

                           干杯

                           沃尔

                           回复

                           1. 只想使用电脑的人甚至不知道 /tmp/ 的存在，因为浏览器等桌面应用程序不会使用它，它也不会显示在桌面图标中，他们会使用 ~/Download 和 ~/Documents 以及 friends。如果担心 /tmp 的文件保留策略，可以找出配置方法。如果不这样做，就会发现困难重重，并在这一过程中学到宝贵的一课。事实上，在其他发行版上并不存在这个问题，这说明所有这些争论都是夸大其词–正如文章标题所暗示的那样。

                           2. 不幸的是，他们确实需要知道这一点……

                              正如别人所说，电子邮件中的附件等东西一般都存储在临时文件中（无论是 c:temp 还是 tmp 还是 yada yada），”我编辑了一个附件并保存了它，我的改动去哪儿了？”这让我很伤心。

                              有些人学会了，可惜有些人学不会。那句话怎么说来着？”人类每发明一个防白痴的东西，大自然就会发明一个更好的白痴”。

                              我知道人们对 Debian 被拖入 21 世纪感到不满，但这并不意味着 21 世纪就比 20 世纪更好……

                              干杯

                              沃尔

7. 重要

   回复

   1. 我以前讲过这个故事，但现在想起来仍然觉得好笑。我曾经支持过一个用户，当时他使用 MS Mail（Exchange 之前），他就是这么做的。他们让我帮他们腾出桌面空间（可能是 20MB 的硬盘），于是我看了看四周，清空了他们已删除的电子邮件文件夹，这似乎是明智之举。他们吓坏了，因为那是他们保存重要邮件的地方，因为删除邮件只需按一次键，而在文件夹中存档则需要按更多的键。

      回复

      1. 我也遇到过同样的情况，只不过那是 Windows 的 “回收站”。

         他们的理由是什么？他们把用完但以后可能会用到的东西放在回收站里。他们会在月底清空它。

         鉴于现实世界的类比，这显然很荒谬，你说呢？但事实并非如此。清洁工有严格的指示，不能清空这个人真正的垃圾桶。原因是一样的。

         网络备份不包括 “回收站”。这些物品很久以前就被转移到那里了，已经超出了备份保留时间。有人顶替他们的工作，清空了回收站。这很有趣。

         回复

      2. 这是一种适用于用户的海勒姆定律。无论文件夹标签上的 “已删除 “字样有多么醒目，但可以观察到的行为是，发送到这里的项目**不会被删除，除非有明确的进一步步骤。人们会依赖这一点。

         回复

         1. 是的，我工作时使用的是 outlook webmail，那里有一个已删除文件夹，把东西放在那里显然不会删除任何东西，但如果我主动删除了已删除文件夹中的东西，我就可以选择恢复它，时间大概是一个月。

            回复

   2. 我第一次尝试在 tmpfs 上使用 /tmp 系统（fedora）时，在 /tmp 中下载了一个 .iso。这触发了 OOM 杀手，杀死了 wayland。

      因为我胆敢使用 /tmp，我的整个会话都被杀死了。它甚至还没满。

      在这一点上，如果我们不想使用 /tmp，那就干脆不要 /tmp。

      回复

      1. 这就是内存不足、/tmp-in-RAM 和没有交换的糟糕组合。

         从长远来看，/tmp-on-disk 也救不了你。

         回复

         1. 内存不够？这完全是一台配备 8GB 内存的普通笔记本电脑，不是什么低成本的嵌入式板卡。

            重新安装就可以了。所以这只是系统默认设置的问题。

            总之，我们不要忘了，几十年来，网上的建议一直是 “不要创建交换”。因此，一旦用户开始在系统中使用这个程序，可能会有成千上万个没有 swap 的安装程序（不是我的安装程序）开始崩溃。

            回复

            1. 我不知道是谁建议人们不要创建交换分区……是那些想卖给你更多内存的新盒子的人吗？

               无论如何，在笔记本电脑上，休眠（挂起到磁盘）也需要交换空间。

               回复

               1. 互联网上的人。在谷歌上搜索 5 秒钟就能找到他们的用户名。如果你想要他们的真实姓名和地址，我帮不了你。

                  暂停到磁盘会很慢，暂停到内存会很快……另外，如果你的交换空间里满是 /tmp 的内容，无论如何你都无法休眠。

                  回复

                  1. 当电池电量耗尽而需要关机时，挂起到 RAM 也无济于事。

                     因此，不要用你的 /tmp 填满整个交换空间。它默认限制在 RAM 的一半是有原因的。这主要与/tmp-in-RAM无关，如果（当……）浏览器出现内存泄漏，并在你想休眠时吃掉整个RAM+Swap，你也会遇到同样的问题。

                     回复

               2. 有些虚拟机和容器环境会*严重*过度提交 IO。如果工作负载与之匹配，这就很有意义了。我见过允许的可持续 IOPS 低至 100，甚至最高只有 500。

                  大量交换很容易超过这些值。如果交换同时发生在许多虚拟机上，可能是因为它们运行了相同的错误软件或遇到了相同的问题数据，那么整个集群可能会遇到真正的麻烦。

                  但是，在所有情况下，只要你的存储能提供足够的保证，你就真的应该使用交换。

                  回复

            2. > 总之，我们不要忘记，几十年来，网上的建议一直是 “不要创建交换”。

               这只是个蹩脚的建议。

               生活中处处都有这种情况。为什么世界要屈从于某人在互联网上写下并传播的错误言论？你不会看到疫苗中心因为反疫苗的胡言乱语而关闭吧：-)

               回复

               1. > 无论如何，我们不要忘记，几十年来，网上的建议一直是 “不要制造交换”。

                  > 这只是个蹩脚的建议。

                  这是过时的建议，7200 转/分的台式机硬盘每秒能完成 72 次寻道。我有很多工作负载，在没有交换的情况下可以正常运行（或者至少会被OOM杀死），但启用交换后机器就会完全挂掉。

                  使用固态硬盘后，问题消失了，所以再次启用交换功能是合理的。

                  回复

                  1. > 我有很多工作负载，在没有交换的情况下工作正常（或至少被 OOM 杀掉），但启用交换后机器就完全挂掉了。

                     我大胆猜测，这意味着 `vm.swappiness` 被设置成了错误的值。

                     回复

                     1. 我当时用真实和合成工作负载做了一些实验，唯一有效的方法就是减少交换容量。

                        当时磁盘的连续读取速度为 150M/秒，但随机存取 4K 块的速度只有 288K/秒。这是 7200RPM 台式机硬盘的典型性能。

                        当交换容量稍大时，性能悬崖就会出现，以至于我直接关闭了交换容量。

                        回复

            3. > 总之，我们不要忘记，几十年来，网上的建议一直是 “不要创建交换”。因此，一旦用户开始在自己的系统中使用 “swap”，可能会有成千上万没有 “swap”（不是我的系统）的系统崩溃。

               别忘了，在 2000 年左右，也就是 linux 2.4，具体细节记不清了，Linus 决定强制重写内存管理/交换代码。这时候，那些运行香草内核、不看发行说明的人突然发现，”swap应该是内存的两倍 “这个老掉牙的说法是真的。任何没有那么多交换容量的系统都会在调用交换代码的瞬间崩溃。注释中的指南说 “没有交换，或至少两倍内存。两者不可兼得”。

               即使在那个时候，也有很多人多年来一直相信这是一个老掉牙的传说。

               这就是为什么我的机器总是有大量的交换空间。这在今天可能完全没有必要，但从来没有人回来对我说 “是的，重写确实删除了这一要求”–他们只是认为，因为每个人都说 “两次交换 “是老太太的唠叨，所以就一定是这样，尽管这在本世纪左右被证明是大错特错的。

               干杯

               沃尔

               回复

8. 忘了提几个替代方案：

   /var/lib/<something>：不清理，通常没有限制，对你的服务有用

   /var/cache：类似于 /tmp，但用于保存较长时间的数据，但你必须期待它们被清理。

   我个人会选择 /var/lib，但你必须自己清理。

   回复

9. 他们也修复了 Emacs 吗？以前 Emacs 会把 emacsclient 连接到的套接字放在 /tmp 中。

   回复

   1. 如果连一个很小的套接字文件都不能可靠地保存在 /tmp 中，因为它可能会被不可预测地删除，那么 /tmp 究竟能用来做什么呢？

      回复

      1. 套接字不应该存放在 /tmp。/tmp 在世界上是可写的，使用时需要特别小心，首先要通过 mktemp 随机生成子目录，否则很容易被无权进程劫持–但这意味着路径是不可预测的，因此需要一个侧信道将其安全地传递给套接字的客户端，这就失去了意义。系统服务可以使用 /run，用户进程可以使用 XDG_RUNTIME_DIR（也在 /run），因为它们有适当的权限。

         回复

         1. 是的，我知道 /tmp 符号链接攻击和其他攻击的问题。正如你所说，这是一个雷区。那么，在这种情况下，/tmp 是否有**合理的用途？原则上，没有长期运行的任务可以使用它，因为旧的临时文件可以被删除……但 “长期运行 “和 “旧 “的定义很难确定。可靠的软件不可能使用一种一开始有效，但一两周后就失效的机制。

            回复

            1. 当然，/tmp 也有用途。有很多。我的电子邮件阅读器在那里存储附件。你的编译器会把临时文件写入 /tmp。initramfs 生成器也是如此。等等。

               如今，暂存文件的正确位置是 /run/user/’uid’/。

               回复

               1. 是的，这是私人数据的抓取区（再次强调：与 mktemp 和朋友一起使用），随时都可能丢失。这里不适合共享数据。

                  回复

                  1. 我的问题是，什么数据是 “可以随时丢失的”？我很难想出例子。大多数情况下，如果软件使用的临时文件被删除，软件就会崩溃。有一些应用程序需要纯粹的缓存，即使缓存文件被删除也能继续工作，但目前大多数使用 /tmp 的用户都不是这样的。

                     回复

                     1. 如果真的有软件希望把关键文件放到 /tmp 中，一周以上不碰它们/访问它们，而当它返回时却找不到它们，那么这个软件就是坏了。正如 https://systemd.io/TEMPORARY_DIRECTORIES/ 上所解释的那样，它可以通过多种方式修复。

                        但我不确定它是否真的存在，这听起来真的像个稻草人。

                        回复

                        1. 我不敢肯定。一般来说，”任何可能出错的事情都会出错”，一个原本不需要花费一周时间的程序最终可能会花费一周时间–毕竟，它不会对所花费的时间进行明确的检查。攻击者有可能注意到使用的文件名，安排阻止目标进程，让其临时文件被清除。然后再创建一个相同名称的新文件。

                           当然，这只是推测，但在一代人之前，蓄意哈希碰撞的想法会被视为稻草人，或许多类似的 “不要这样做 “或 “永远不会发生 “的情况。

                           由于收割期被定义为至少 10 天（并不纯粹取决于站点），这就消除了人们在实践中的许多担忧。

                           回复

                           1. 如果 “攻击者接管文件名 “是威胁模型的一部分，就不要使用 /tmp_ 来处理该数据–没有如果，没有但是，就是不要。

                              当我说 “我并不是在寻求哲学讨论或个人偏好或假设清单 “时，所有这些折磨人的稻草人正是我的意思。如果新的默认设置对你不起作用，只需进行微不足道的单行配置更改即可。争论为什么你的首选配置才是真正的默认设置，而其他配置都是错误的，只会浪费时间，根本不会有任何效果。

                           2. 如果 “攻击者接管文件名 “是威胁模型的一部分，_不要使用 /tmp_ 来处理该数据

                           3. 这确实取决于威胁模型和对策等。在 mktemp 子目录中使用 O_TMP（模板中要有足够多的字符），很可能可以安全地防止先发制人的劫持，而且价值也不高–缓存什么的。但如果有什么值得窃取的东西，就不要使用 tmp，因为有很多更安全的替代方案，而且也不是什么新东西–XDG_RUNTIME_DIR 已经存在了至少十年，甚至更久。

                              对于套接字–就是不要。老实说，现在仍有程序在这么做，比如 tmux，实在令人费解。

                        2. > 该软件根本就是坏了

                           不，它没坏。在你开始删除文件之前，它一直运行正常。

                           > 它可以通过多种方式修复

                           是的，但你在这里破坏了现有的用户空间。但你破坏的是现有的用户空间。

                           内核破坏用户空间和 systemd 破坏用户空间有区别吗？

                           我真的很恼火。

                           你能不能给出一个合理的理由，为什么你非要在 /tmp 中删除几个字节，而这几个字节在 /tmp 中安然无恙地存在了 10 天？

                           如果我们谈论的是兆字节或千兆字节的话。好吧。好吧。制定一个清理策略，因为它确实有帮助。

                           但删除小文件和套接字？别这样。这样做对任何人都没有帮助，但却有很大的破坏空间。

                           回复

                           1. > 不，它没坏。在你开始删除文件之前，它一直运行正常。

                              是的，它是坏了，不，它没有坏，正如文章开头所说，这在其他发行版上已经是十年前的常规了。

                              > 但你正在破坏现有的用户空间。

                              什么都没破坏，这是无稽之谈。别浪费时间了，写一行配置文件，按自己的需要定制你的机器吧。抱怨改变不了什么。

                              > 但是删除小文件和套接字？别这样。这样做对任何人都没有帮助，但却有很大的破坏空间。

                              大小限制并不是唯一的问题，特别是在 tmpfs 上还有一个 inode 限制，而用零大小的文件使 tmpfs 饱和是很有可能的，DOS 也会使用 /tmp 的其他功能。因此，删除未使用的小文件和删除大文件一样重要，以确保共享资源的可用性。

                           2. >特别是在 tmpfs 上，也有一个 inode 限制，用零大小的文件使 tmpfs 饱和是很有可能的，而且 DOS 还会使用 /tmp 的其他功能。

                              好吧。你能给我们一些数字，并说明这不是 “无稽之谈”（引用你自己的话）吗？

                              必须创建多少文件才能耗尽可用空间？

                              现实世界中哪些应用程序会受到影响？

                              传统的基于磁盘的 /tmp 肯定也有同样的问题，对吗？所以，从来没有一个版本的 Linux 不存在这个 “问题”。但几十年来，肯定有一些 Linux 版本不会随意删除 /tmp 中的文件。

                              >编写单行配置文件，按需定制你的机器

                              我的机器_是_按照我想要的方式配置的，而你正在改变它。我还没读到为什么需要这样做的合理解释。

                              你在改变用户界面。你正在做的，正是你不断抱怨的事情。

                           3. > 好吧。你能给我们一些数字，并说明这不是 “无稽之谈”（引用你自己的话）吗？

                              这取决于系统，只需检查一下 – df -hi /tmp

                              > 但肯定有几十年的 Linux 系统不会随意删除 /tmp 中的文件。

                              当然有 – 在 Debian 中，tmpfiles.d 在过去约 15 年中一直在删除 /tmp 中的文件，在此之前还有 tmpreaper 这样的东西。其他操作系统，如 Solaris，默认情况下也会删除那里的文件。你在假装这是某种新的、最后一刻才开发出来的东西，其实不是，这已经是历史了。

                              > 你正在改变用户界面。你正在做的正是你不断抱怨的事情。

                              胡说八道。发行版的主要版本一直都在改动，所以我们才会发布 “发行说明”，并在其中注明改动。如果你不想要改变，那就永远使用同一个稳定的 LTS 版本。包括 Debian 在内的发行版从未说过 “我们不会在重大版本升级时破坏兼容性”，恰恰相反，每一个新发行版都会改变一些东西–这就是发行 Debian 新版本的意义所在。你试图得出的平行结论毫无意义，因为内核确实说过 “我们不会破坏兼容性”。这就是区别所在，假装没有区别是愚蠢的。

                           4. >just check it out – df -hi /tmp

                              Ok.

                              >$ df -hi /tmp

                              >Filesystem Inodes IUsed IFree IUse% Mounted on

                              >tmpfs 4.4M 37 4.4M 1% /tmp

                              >$ for i in $(seq 0 100000); do touch /tmp/x/$i; done

                              >$ df -hi /tmp

                              >Filesystem Inodes IUsed IFree IUse% Mounted on

                              >tmpfs 4.4M 98K 4.3M 3% /tmp

                              因此，需要约 450 万个空文件才能填满可用的 inode 空间。

                              我不相信这个限制可以用来论证可能使用的文件必须在 10 天后删除。

                              这个限制是否比应用程序因删除文件而崩溃的频率更高？

                           5. > 我不相信这个限制可以用来证明必须在 10 天后删除可能使用过的文件。

                              这里一定有什么误解–我没有在争论什么，也没有试图说服你什么。我只是在解释事情的运作方式和原因。如果你不喜欢它们的工作方式，那就太糟糕了–你可以自由地对你的机器进行不同的配置，就像已经解释过的那样，你可以自由地对你的笔记本电脑、台式机或服务器进行你认为合适的配置。

                           6. >我不是在争论什么

                              但你应该这么做。你正在改变 Debian 的世界。

                              >你可以自由地对你的机器进行不同的配置。

                              请记住，您正在改变我的机器行为。您改变了 Debian 系统的运行方式，而我却不得不恢复到以前的运行方式。

                              作为维护者，您有责任为您的改变提供充分的理由。你应该能够解释清楚。然而，我并没有看到更多的解释，只是说如果删除文件，你会更喜欢，而且 “别人也会这么做”。

                              作为维护者，责任重大。

                              如果你所做的改动需要数百万人只改动一行配置就能恢复原来的行为，那你就浪费了数百万小时的工作时间。

                              这些更改应该有一个*好的理由。

                           7. > 好吧，但你应该这样做。你正在改变 Debian 的世界。

                              不，他（或其他 systemd 开发者）没有做任何类似的事情。*DEBIAN* 正在改变自己的世界。

                           8. 请在 Debian systemd 软件包更新日志中搜索 “bluca”。

                           9. > 请在 Debian systemd 软件包更新日志中搜索 “bluca”。

                              听起来你需要向 Debian 提交一个发布阻拦 bug，但由于这从根本上是要推翻 Debian 软件包管理者的决定，你可能需要将其升级到 TC 或整个项目的投票。

                              无论哪种方式，你都需要一个比 “我不喜欢它，也懒得做单行配置更改 “更好的技术论据。

                           10. 比这更愚蠢的是，它只在新安装时启用，而不在升级时启用：”我不喜欢它，而且如果要从头开始重新安装，我也懒得进行单行配置更改。

                           11. > 无论如何，你都需要一个更好的技术论据

                               是的。更改不需要技术论证。”只需要一个理由：我已经这样决定了”。(bluca）。而用户需要技术论证来反对它。我明白了，我会尊重它。

                               我一定会牢记这条规则。

                           12. > 更改不需要技术论证。

                               除了无数次解释过 “新 “默认设置的技术优点之外，甚至在这个主题中也是如此。还有一个小细节，Linux 世界的其他地方采用这种 “新 “方式已经有十年之久了。这些讨论（包括技术论证）都是公开记录的一部分。

                               > “只需要一个理由：我已经这样决定了”。

                               我不想打断你，但绝大多数 Debian 软件包都属于这一类–软件包管理者和上游作者每天都会做出无数这样的决定。

                               再说一遍，如果您（或任何人）不喜欢这些决定，请随时援用 Debian 程序来推翻打包者和/或上游的决定。

                           13. 我再说一遍：这些都已经说过了，不会再有人改变主意了（如果有的话）。我想我们现在可以停止这种反反复复的争论了。

                           14. > 请记住，您正在改变我的机器行为。

                               明年发布的下一个 Debian 版本将在很多方面改变您机器的行为，这将记录在（冗长的）发行说明中。如果您喜欢–很好。如果不喜欢–那就太糟糕了，要么重新进行适当的配置，要么继续使用当前版本，直到它退出市场，然后开始花钱请人提供后续支持。

                               > 这些更改应该有一个*好的理由。

                               只需要一个理由：我已经这样决定了。不喜欢？别担心，你可以把钱要回来，给我一个地址，我会给你寄一张 0 英镑的支票。

                           15. (说得迂腐一点，正如更新日志所指出的，事实上，tmpfiles.d 规则并不适用于现有机器，而仅适用于新安装的机器）

                           16. >只需要一个理由：我已经这样决定了。

                               好的。这就是规则，我也将把它应用到您身上。

                           17. 所以……我们似乎又到了这样一个地步：每个人都说了自己的观点–说了好几次–任何可能被改变的想法都已经被改变了。请在这里停止这种来回争论吧。

               2. 但如果编译器将暂存文件写入 /tmp，而这些文件在编译器完成之前被删除，编译器就会崩溃。好吧，删除文件的时间通常比编译运行的时间要长得多，但据我所知，并没有在任何地方对此做出规定。附件也是一样，你可以离开你的桌面去度假一周，然后指望它在你回来时还能正常工作。

                  回复

                  1. 有规定的，/tmp 为 10 天，/var/tmp 为 30 天，其中包括 mtime/atime/ctime。您是真的遇到过这个问题，还是纯粹是基于对其工作原理的粗浅理解而做出的推测？

                     回复

                     1. 那太好了。我一直以为收割期可能是未指定的。

                        虽然一般来说我不喜欢依赖时间的效果，比如套接字连接不活动后的超时，但这也是生活中的事实。

                        回复

            2. 此外，还可以通过 flock: https://systemd.io/TEMPORARY_DIRECTORIES/（或通过 tmpfiles.d ‘x’ 指令永久退出，但效果不佳）轻松可靠地停止自动删除文件。

               回复

10. 30 多年来，我在各种学术和研究领域都看到过 /tmp 是存储日期的地方，原因各不相同。

    1.很久以前，各种系统的主目录都有配额。没有配额的是 /tmp，因为它被视为抓取空间，甚至可能有一个专用磁盘。清理工作通常一年左右进行一次，你甚至可以在其中放置比其他地方更大的磁盘。随着 “共享 “电脑越来越多地转向工作站和个人笔记本电脑，家庭配额之类的东西也越来越少，但在 2009 年，当我离开这个空间时，默认情况下把大文件放到 /tmp 的趋势依然很强。我所见过的关于 Fedora 使用交换/tmp 的抱怨大多发生在学术界，因为某些东西在错误的时间坏掉了，导致数据丢失。

    2.研究和系统管理对时间的定义是不同的。系统管理员可能会认为，/tmp 中存活时间超过一天或一周的文件需要转移到更长久的地方。研究人员可能认为，收集原始数据或其他东西所花的 6 个月时间是暂时的，甚至可能需要一年。这些数据之后可能会被扔掉，所以是 “临时的”。

    再加上 Debian 是 Linux 中的 NetBSD（我这是在夸它）。它是在几十年来从未生产过的硬件系统上移植和维护的，既要在内存为兆字节的系统上运行，又要在内存为兆字节的系统上运行。这就意味着，在 90% 的不同发行版中都能正常运行的一般解决方案，会引起更多的抱怨，因为人们期望自己的 SPARC10（？）或 M68000 系统在 2024 年仍能正常安装。

    我希望在旧版的 Debian 安装程序中，这将是一个需要回答的问题：你希望 /tmp 是 tmpfs、专用分区，还是在 / 上，这样才能实现各种解决方案。我不知道较新的安装程序是否能做到这一点。

    回复

    1. 我所遇到的高性能计算系统往往都有”/scratch”（或类似的）分区，目的正是如此。当文件系统满了之后（根据我收到的邮件，文件系统满了 80% 以上），邮件就会被发送出去，如果事情还在继续，`/scratch`中的东西就会被删除。此外，还有专门的空间用于存放项目成果，这些成果应保存在项目跟踪目录中。这样，操作员就可以对项目的存储空间进行适当的核算（就像对 CPU/GPU 的访问进行核算一样）。如果 `/tmp`在真正同时运行的机器上被这样使用，我会很惊讶：

       – 未计入项目

       – 不受共享限制

       – 预期会长期存在

       – 对机器所有者的任务至关重要

       – 操作员的审查如此松懈，以至于 Debian 默认的更改会无声无息地出现（不过考虑到前两点，也许它们真的只是疏忽程度上的差异而已）

       回复

11. 有点遗憾的是，这将导致 Guix 软件包开箱即不可靠。编译确实是在 /tmp 中进行的，但它们很少能装入 RAM（例如，firefox 需要 12GB 的磁盘空间，Linux 内核需要 18GB 的磁盘空间），因此有些软件包会编译失败。我想知道如何解决这个问题。

    也许 /tmp（默认情况下）应该有合理的大小（比如 50GB），并在默认情况下创建足够大的交换空间？

    回复

    1. 如果你喜欢用 “make -j ‘nontrivial'”来构建 firefox 或内核，那么你应该有足够的技术知识来调整你的 tmpfs 设置，使其正常工作。

       或者，guix 也可以帮你做到这一点。

       回复

       1. 我不明白”-j whatever “与 /tmp 的使用量有什么关系。内存使用峰值与此有关联，但与磁盘空间无关。如果没有 -j，磁盘使用量会增长得慢一些，但也会达到相同的峰值。

          我想说的是，有些程序会在 /tmp 中合法地使用多个千兆字节，而 “tmpfs 的最大大小为内存的 1/2 “对它们不起作用。我以由 debian 打包的 guix 软件包为例，因此让它开箱即用似乎是合理的。

          回复

          1. 可以简单地将此类软件包配置为使用 /var/tmp 等其他设备，然后

             回复

          2. > 我不明白”-j whatever “与使用 /tmp 有什么关系。

             根据编译的内容，每个编译线程都会占用一定的临时空间。我就遇到过几次这样的情况，不过一旦我知道是怎么回事，就很容易解决了。

             > 我想说的是，有些程序会在 /tmp 中合法地使用许多千兆字节的空间，而 “tmpfs 的最大大小为 RAM 的 1/2 “对它们不起作用。

             tmpfs 在超过 RAM 大小的情况下也能正常工作。只需添加 swap（使用 zswap 效果更好）并相应调整大小即可。这就是我的解决方案，我的系统因此变得更好了。无论如何，系统都应该使用 swap，而 tmpfs 默认使用的大小应与 swap 或 50% RAM 大小相匹配，以两者中较大者为准。

             回复

12. 对这种情况感到困惑。除非有必要，否则你不会编写使用临时文件的程序，例如未知输入集或已知输入集超过内存。在内存足够使用的情况下，几乎没有其他理由去设计使用文件系统的程序。

    而现在却有人说：”惊喜吧，我们把你的文件系统移回了内存，但没关系，因为如果你的内存用完了，我们会把你的一半系统（包括绘制鼠标指针的功能）分页到磁盘上，所以现在你也必须启用交换功能”，坦率地说，这只会激怒我。

    我不知道为什么还有人在关注堆栈的这一部分，也不知道谁在为这项工作买单，这只是为了绝对愚蠢的收益而制造愚蠢的破坏。我懒得理会列表主题，但我想这些模糊的感觉应该没有任何有意义的指标来支持吧？

    回复

    1. > 不关心列表主题

       我也是。

       回复