Linux tmpfs 怎样判断内存文件系统是否合适

如果目录里的数据可以在服务重启后重新生成，且你希望减少磁盘 I/O，Linux tmpfs 可能合适；如果数据必须跨重启保留，或者写入量没有可靠上限，就不应该把它当作普通磁盘使用。判断的核心不是“内存盘是否更快”，而是同时回答三个问题：数据能不能丢、最多会占多少内存、文件数量会不会失控。

结论：tmpfs 适合缓存、构建中间产物、短生命周期的临时文件；不适合唯一副本、无界日志和无法承受内存压力的长期数据。卸载 tmpfs 后其中的文件会消失，页面也会计入内核的共享内存统计。

官方文档：https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html

先判断数据是否值得放进 tmpfs

tmpfs 的文件存放在虚拟内存中，不会像普通磁盘文件那样直接创建在硬盘上；内存紧张时，tmpfs 页面在默认配置下可以被换出到 swap。它因此适合“快一点但可重建”的数据，不等于拥有一块不会丢失的 RAM 磁盘。

可以先按下面的分界判断：

先确认挂载类型，再看容量和 inode

不要只根据目录名判断。一个名为 /run/app-tmp 的目录可能是普通目录、bind mount，也可能已经挂载成 tmpfs。先查目标路径对应的文件系统：

# 用目标路径反查真实文件系统类型和挂载选项
findmnt --target /run/app-tmp --output TARGET,FSTYPE,SIZE,USED,AVAIL,USE%,OPTIONS

# 容量和 inode 分开查看，避免只看百分比漏掉文件数上限
df -h /run/app-tmp
df -ih /run/app-tmp

# 目录实际占用用于定位谁在消耗空间，不替代 df 的文件系统额度
du -sh /run/app-tmp

findmnt 负责确认挂载点和类型；df -h 反映这个 tmpfs 实例的容量额度；df -i 反映 inode 额度。大量零字节小文件可能先耗尽 inode，而不是先耗尽字节空间，所以只看 df -h 不够。

还要注意，/proc/meminfo 中的 Shmem 不只包含用户可见的 tmpfs，也可能包含共享内存。要判断某个挂载点的使用量，优先把 df、du 和应用自己的文件数量统计放在一起看。

用 size、nr_inodes 和权限给 tmpfs 设上限

确认数据可以丢之后，再给它一个不会吞掉整机资源的边界。内核文档说明，默认 size 通常是物理内存的一部分；把实例设置得过大，可能让内存回收变得困难。生产配置不要依赖默认值，应该显式写出容量、inode 和目录权限。

# 创建挂载点；目录本身不代表已经使用 tmpfs
sudo install -d -m 0750 /mnt/app-tmp

# 给临时目录设置 2 GiB 字节上限、20 万个 inode 和最小访问权限
sudo mount -t tmpfs -o size=2G,nr_inodes=200k,mode=0750 tmpfs /mnt/app-tmp

# 重新读取挂载参数，确认实际边界而不是只看配置文件
findmnt --mountpoint /mnt/app-tmp --output TARGET,FSTYPE,SIZE,OPTIONS

size 限制可分配的字节数，nr_inodes 限制文件和目录等 inode 数量，mode 控制初始根目录权限。容量与 inode 应按应用峰值估算并留出余量；不能用“机器还有多少空闲内存”代替 tmpfs 的上限设计。

如果要调整容量，可以使用 remount，但不能把它缩小到低于当前使用量；权限也可以在挂载后用常规权限命令调整。若数据不能承受 swap 带来的延迟，可以评估 noswap，但这会把内存压力更直接地留在物理内存和回收路径上，不能简单理解成“更快”。

把内存压力和重启行为纳入最终决策

最后不要只问“挂载是否成功”，而要看它在峰值场景下是否仍然可控：

1. 按并发任务估算临时文件峰值，并把峰值写进 size，不要使用无界配置。
2. 按文件数量估算 inode 峰值；缓存键很多时，nr_inodes 比字节容量更早成为瓶颈。
3. 明确 swap 策略。默认允许换出并不保证延迟稳定，禁用 swap 也不代表可以忽略内存不足。
4. 把卸载、重启、容器重建和服务异常退出列入恢复演练，确认目录里的内容确实可以重新生成。

一个实用的上线判定是：数据可重建、容量有明确上限、inode 有明确上限、权限符合最小暴露原则、服务有内存压力监控，并且团队接受卸载后清空的事实。只要其中一项无法满足，继续使用持久化文件系统通常更稳妥。

常见问题

tmpfs 一定完全不使用磁盘吗？

tmpfs 的文件不会直接创建在硬盘上，但默认情况下页面可以在内存紧张时换出到 swap。它仍然不具备持久化语义，卸载后文件会丢失。

为什么 df -h 还有空间，创建文件却失败？

可能是 inode 已经耗尽。用 df -i 查看 inode 使用率，并结合应用创建文件的数量和命名策略排查。

可以把 tmpfs 的 size 写成整机剩余内存吗？

不建议。其他进程、页缓存、内核和共享内存也需要资源，tmpfs 应该使用基于业务峰值和安全余量计算出的显式上限。