Linux tmpfs 挂载后空间为何还不够：size、inode 与内存回收的排查顺序

tmpfs 报满时，先别只看 df -h。它同时受字节容量、inode 数量和可回收内存影响：容量还有余量时，inode 用尽仍会创建失败；挂载参数看似放大了，机器的内存压力又可能让业务出现抖动。下面用一套短命令把这三个限制拆开，最后再决定是清理、调整挂载参数，还是回到业务写入模型。

排查顺序固定为 df -h 看容量、df -i 看 inode、findmnt 核对真实挂载参数，再用内存回收指标判断是否已经把 tmpfs 当成了无限缓存。

你在 Linux 中挂载完 tmpfs 后明明看着配置的空间不小，用不了多久就提示存储已满没法写入，排查时 df -h 查看到还有剩余空间也摸不着头脑，这类问题一般出在 size 上限逻辑、inode 占用耗尽、底层内存回收规则这几个点，按固定顺序排查很快就能定位。

很多时候你遇到的不是 tmpfs 物理空间不够，是配额、索引节点或者底层内存边界先触发了限制，直接加 size 参数只会延后故障，没法根除问题。

先把“空间不够”拆成三个问题

同一个 ENOSPC 可能对应不同原因。块容量不足时，df -h 的 Use% 接近 100%；inode 用尽时，df -i 会先到 100%，即使字节容量还很宽裕；而内存压力通常不会把它表现成一个简单的容量百分比，需要结合 free、vmstat 或容器的 memory.events 判断。

这也是为什么“把 size 改大”经常没有立即解决问题：它只能改变挂载的容量上限，不能增加 inode，也不能绕过容器的内存限制。

最小检查：容量、inode 和真实挂载参数

mountpoint /run/my-tmpfs
df -h /run/my-tmpfs
df -i /run/my-tmpfs
findmnt -no TARGET,FSTYPE,OPTIONS /run/my-tmpfs

先确认目标确实是 tmpfs，再记录四个值：总容量、已用容量、inode 总数、inode 已用数。findmnt 是关键核对项，它能发现你查看的 unit、容器配置或启动脚本并不是当前生效的挂载来源。

容量接近上限时看谁在占用

du -x -h -d 2 /run/my-tmpfs | sort -h | tail
find /run/my-tmpfs -xdev -type f -printf '%s %p\n' | sort -n | tail

tmpfs 里的目录结构通常比磁盘短命，但排查命令仍要限制在挂载点内。du -x 可以避免跨到其他文件系统；生产环境不要直接删除未知文件，先确认文件的打开者、生命周期和是否能由服务重建。

inode 接近上限时看文件数量

find /run/my-tmpfs -xdev -type f | wc -l
find /run/my-tmpfs -xdev -type d | wc -l
find /run/my-tmpfs -xdev -type f -printf '%h\n' | sort | uniq -c | sort -n | tail

大量零字节文件、分片临时文件和按请求生成的小目录，都会消耗 inode。此时删除过期文件或降低单次分片数量，比单纯扩大 size 更直接。

三种处理方案怎么选

处理动作可分为清理、重挂载和改业务写入方式。它们的风险不一样：清理见效快但需要先确认临时文件生命周期，避免误删运行中数据；重挂载改变上限且可能影响已有文件的访问状态；调整业务写入逻辑最稳妥，却需要走发布和回归验证流程。

调整 size 前先确认内存边界

free -h
vmstat 1 5
grep -E 'MemAvailable|Shmem|SwapFree' /proc/meminfo
findmnt -no OPTIONS /run/my-tmpfs

tmpfs 使用的内存会随文件写入增长，并不等于挂载时就预留全部上限。检查主机可用内存、共享内存相关指标，以及容器是否有更小的 memory limit。若运行在 cgroup v2，继续查看：

cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.events

如果 memory.max 是有限值，挂载参数放得再大也不能突破该边界。调整时先在低峰期执行，记录变更前后的容量、inode 和内存值，并保留原挂载参数作为回滚依据。

一个可复查的验收顺序

# 1. 记录基线
date
df -h /run/my-tmpfs
df -i /run/my-tmpfs
findmnt -no TARGET,FSTYPE,OPTIONS /run/my-tmpfs

# 2. 做一笔受控写入，再立即删除
testfile=/run/my-tmpfs/.tmpfs-write-check
dd if=/dev/zero of="$testfile" bs=1M count=8 status=none
sync
stat "$testfile"
rm -f "$testfile"

# 3. 复查并确认没有异常增长
df -h /run/my-tmpfs
df -i /run/my-tmpfs

验收要包含删除后的复查，避免测试文件本身成为新的垃圾。对服务目录还要补一次真实业务路径测试，并观察日志是否仍有 ENOSPC。

容易误判的边界

• 把 size 当成预留：它通常是可使用上限，不代表这部分内存已经提前锁定。
• 只看容量百分比：大量小文件会先耗尽 inode。
• 跨挂载点统计：没有 -x 的遍历可能把问题扩大到其他文件系统。
• 直接重启服务清空目录：tmpfs 的内容可能会消失，但这不等于修复了持续写入的根因。

相关问题

tmpfs 能不能替代持久磁盘？

tmpfs 不适合存放需要持久留存的数据，它适合缓存、运行时 socket、短期中间结果等可重建数据；需要重启后保留的文件应使用持久存储。

为什么删除文件后空间没有马上回落？

如果进程仍打开已删除文件，目录项消失但数据仍被占用。可用 lsof +L1 查找这类文件，再按服务生命周期处理。

先扩大 size 还是先清理？

不要一碰到 tmpfs 报满就直接调大 size 参数，先确认是容量、inode 还是内存边界。只有容量确实是业务需要且内存预算允许时，才扩大上限；否则优先修复清理和分片策略。

总结

tmpfs 的排查不靠猜：df -h 负责字节容量，df -i 负责 inode，findmnt 负责确认生效参数，内存与 cgroup 指标负责判断回收边界。把这四类证据放在同一张变更记录里，再选择清理、调整或改业务，故障才不会在下一次流量高峰重新出现。