给服务一个私有临时目录，为什么还可能把空间用光？

诊断服务有独立运行目录，也能在退出时清理。一次大输入却产生了多份中间结果，暂存空间迅速增长。目录归属与生命周期解决了部分问题，容量还需要单独约束。

本文分清文件系统限制、应用预留和失败恢复，给出预算演示。没有挂载 tmpfs、修改服务或填满磁盘；实际只执行内存中的预算断言。

先确认限制的是哪一层

层次	可以限制什么	不能自动保证什么
独立目录	归属、命名与清理范围	单独的字节配额
独立文件系统或配额	总容量、文件数量等	每项任务公平使用
应用预留	接纳前估算与并发预算	写入绝不超限
失败处理	停止任务、清理与报告	所有异常均能恢复原状

RuntimeDirectory= 一类配置不能仅凭名字就被当成容量上限。实际后端、挂载与配额要查清楚，不能拿一个私有路径替代存储预算。

tmpfs 也有明确资源边界

Linux tmpfs 官方文档说明了 size 与 inode 等限制，以及它使用内存并可能涉及交换空间的特点。它不是不占资源的“临时盘”，也不是文件放进去后就不必管总内存。

在 systemd 的受控实验服务里，可以核对systemd.exec的 TemporaryFileSystem= 支持与条件，再评估类似片段：

[Service]
TemporaryFileSystem=/tmp:rw,size=64M

这是待验证示例，不是已部署配置，也不是推荐容量。它改变服务看到的相关路径环境，可能影响依赖程序；还需核对运行身份是否能创建所需文件，以及是否有原路径内容被遮蔽。本文没有应用它，更没有与其他隔离选项混用后宣称通过。

容量不能只看字节。大量小文件可能先耗尽文件数量相关资源；删除了目录项但进程仍持有对象，也可能使可见目录大小与实际占用不一致。要将具体指标与文件生命周期对应起来。

接纳前保留任务预算

假设总预算 64 MiB，一项任务估计需要 40 MiB，再来一项需要 32 MiB，应先拒绝或等待，而不是两边同时开始写。下面是单线程的最小预留演示：

limit = 64 * 1024 * 1024
reserved = {}

def reserve(task, size):
    if task in reserved or size < 0:
        raise ValueError("invalid request")
    if sum(reserved.values()) + size > limit:
        return False
    reserved[task] = size
    return True

本地检查确认 40 MiB 预留后无法再接纳 32 MiB，删除前一项预留后，32 MiB 可通过。这些数字是构造预算，不是设备实测。

代码没有处理多线程、跨进程或崩溃恢复；并发读改需要协调，否则可能同时通过检查。预算应覆盖输入副本、中间结果、导出暂存与必要余量，不能只按原始文件大小估算。

实际增长也可能超过估计。应用需要单任务上限和写入阶段检查，超出后停止并说明原因。预留不是磁盘空间锁，更不能替代每次写入返回值的检查。

写入失败后要留下可解释状态

空间不足时，不要把半成品当成完整报告交付。应标记导出失败、保留必要任务状态，清理自己明确拥有的暂存对象。清理也可能失败，需记录路径归属与原因，避免下一次启动按模糊前缀删除无关文件。

检查剩余空间只能帮助预判。检查之后其他任务仍可能写入，文件系统也可能因其他条件失败，所以不能承诺“空间检查通过就一定完成”。

若程序用缓冲输出，错误可能在刷新或关闭时才显露。结束阶段同样要检查，不只看最初创建文件成功。本文没有制造这些失败，保留为后续受控演练项。

观测与默认值从任务来

目标设备上记录正常与突发任务的输入量、中间放大比例、并发数、容量峰值和清理后基线。若有现成工具，再读取挂载、字节与 inode 使用等信息；本文没有执行 Linux 观测或安装软件。

第一次可以先缩小输入和并发范围，确认失败语义，再扩大。过紧的容量会增加重试，过松又不能保护环境；合适值需要实际任务证据，不能从演示中的 64 MiB 直接复制。

资料与验证范围

• 官方依据：Linux tmpfs、systemd.exec。
• 已执行：内存中的任务预留、超预算拒绝与释放后恢复断言。
• 未执行：tmpfs 挂载、服务配置、磁盘或 inode 耗尽、写入失败、Linux 观测、浏览器、真实 API 和生产构建。没有容量推荐或实测峰值。