☰

systemctl 启用 tmp.mount

tag-icon • tag-icon linux ram tmp systemctl caching
systemctl 启用 tmp.mount

考虑在基于 tmpfs 内存的文件系统上挂载 /tmp 目录的做法，可以通过以下方式完成： systemctl enable tmp.mount

并考虑以下事项：

理由之一：对不同路径使用单独的文件系统可以保护系统免受因文件系统已满或故障而导致的故障。

-

另一个理由：当使用内存而不是磁盘时，一些在 /tmp 目录中写入文件的应用程序可以看到巨大的改进。

磁盘缓存是否始终有效？我的意思是当你写信给任何文件夹（不仅仅是/tmp）你可能无论如何都会写入RAM，直到它被刷新到磁盘......内核在幕后处理所有这些，我认为我不需要去干预调整事情。那么这样做systemctl enable tmp.mount有任何实际价值吗？如果有的话又怎样呢？

另外（在 CentOS-7.6 中）我正在对此进行测试，以尝试了解我正在经历的情况：

  • CentOS 7.6 安装在一个 500GB SSD 上，简单的磁盘分区如下
    • 1GB/dev/sda1作为/boot
    • 100MB/dev/sda2为/boot/efi
    • 475GB/dev/sda3作为/
  • PC 具有 8GB DDR-4 RAM
  • 如果我这样做systemctl enable tmp.mount我就会得到
    • 3.9GBtmpfs为/tmp

这tmpfs /tmp at 3.9GB比默认方式有什么更好的地方，默认方式（a）由于磁盘缓存，首先基于 RAM 拥有高达约 8GB 的​​容量，（b）然后当基于 8GB RAM 的容量进行磁盘缓存时，有 > 400GB 的可用磁盘使用 ？

答案1

此配置是否“增加价值”完全取决于所讨论的用例。 “好”、“坏”，这些对于没有上下文的不同配置选项来说不是有效的标签。

对于具有大量 RAM 和高事务数的系统，tmpfs 文件系统可能会提高性能（例如：2 类虚拟机管理程序）。这可能是“好的”用例。

或者，具有少量 RAM 但具有大量存储空间的系统（例如：当今制造的任何物联网垃圾）可能在物理写入 /tmp 存储设备时表现更好，因为内存中的任何内容都可以写入交换，如果未充分利用（如果交换也被激活）。这可以被认为是 tmpfs /tmp 的“坏”情况。

答案2

当您使用 挂载路径时tmpfs，默认大小是物理内存的一半。只要您的系统没有内存压力，您放置在那里的任何文件都将保存在内存中，并且不会接触磁盘。

这与写入实际持久存储（如旋转磁盘、SSD 或 nvme）上的文件形成对比。如果你有 500GB 的空闲内存，并且你对旋转磁盘上的文件进行了 1GB 的打开-写入-关闭操作，内核将为你做一些事情：

  • 内核会为你缓冲写入
  • 如果您的文件系统是日志文件系统（例如，当今使用的大多数文件系统，如 ext4、xfs、btrfs、zfs），它将首先缓冲相应的日志写入。
  • 内核将在适当的 I/O 空闲期或截止日期期间刷新其缓冲区（以适当的顺序），具体取决于配置的 I/O 调度程序
  • 即使您在这种空闲发生之前创建、写入和删除了该文件，内核最终也会更新封闭目录的修改时间。

tmpfs 仅在整体系统内存使用量足够高以至于应用程序（以及任何进程）使用足够的内存需要交换到磁盘时才接触磁盘。 tmpfs 块像任何其他应用程序的内存一样被调出并写入交换。如果您禁用了交换，那么您的内核将开始终止进程​​以释放内存。但除此之外，没有任何东西接触磁盘。没有日志，没有创建/访问/修改时间戳，没有用户权限，什么都没有。当您使用 tmpfs 时，您是在说“将这些文件与其他所有文件一起保存在内存中，并将它们视为可遗忘的主内存”。

tmpfs 出现时绝对令人惊叹，并且取代了几乎所有其他在 Solaris/Linux 中制作“ram 磁盘”的方法（我不记得它还移植到了哪里）。

相关内容