ulimit -f 不适合防范磁盘写满，因其仅限制单次 write() 系统调用字节数，无法控制实际磁盘占用、绕过行为多、不约束多文件总和，且依赖程序主动错误处理。
ulimit -f 不能限制单个进程创建文件的物理大小上限，它限制的是该进程所有打开文件的 单个文件写入字节数上限（即 write(2) 系统调用最多允许写入的字节数），而非文件在磁盘上的实际占用空间。更关键的是：这个限制对大多数现代应用（尤其是使用 buffered I/O、mmap、或日志轮转机制的程序）几乎无效，且无法防范“写满磁盘”的根本风险。
为什么 ulimit -f 不适合防范磁盘写满
• 它只影响 write() 系统调用返回值：当累计写入字节数超过限制时，write() 返回 EFBIG 错误，但程序可能忽略该错误继续运行，或崩溃前已写入大量数据；
• 不控制文件系统级空间占用：稀疏文件、多硬链接、内存映射写入（mmap+MS_SYNC）、直接 I/O（O_DIRECT）等行为完全绕过 write()，不受 -f 限制；
• 无法限制多个文件总和：一个进程可同时打开 100 个文件，每个写 999MB（若设为 1G），总空间仍可达 100GB；
• 不影响已有文件追加：如果文件已存在且小于限制，后续 write() 可能因 offset 超限失败，但 truncate、fallocate、甚至 unlink+recreate 都可规避。
真正有效的磁盘空间防护手段
• 使用 cgroups v2 的 io.max 或 memory.low + oom_kill：对进程组设置 I/O 写入带宽/bytes 限额，或通过内存压力触发 OOM Killer（间接限制缓存刷盘行为）；
• 挂载时启用配额（quota）或 project quota：为用户、组或 project ID 设置磁盘空间硬限制，内核级生效，无法绕过；
• 应用层日志轮转 + 外部监控：用 logrotate 配合 maxsize 和 rotate，并用 inotifywait 或 df -h 定期检查关键挂载点使用率（如 >85% 触发告警或 kill 进程）；
• tmpfs / ramfs 限定临时文件：将易失控的临时目录（如 /var/log/app-tmp）挂为 tmpfs 并指定 size=512M，超限直接报错 ENOSPC，比磁盘写满更早暴露问题。
如果仍想尝试 ulimit -f，请注意正确用法
• 它必须在目标进程 启动前 设置：
ulimit -f 1048576 # 单位是 KB，即限制单次 write 最多写 1GB（注意：不是文件最大 1GB）
./myapp &
• 实际效果需程序主动检查 write() 返回值 —— 绝大多数语言 runtime（Python/Java/Go）默认不校验，会静默截断或 panic；
• 在 systemd 服务中应写在 [Service] 段：
LimitFSIZE=1048576
但同样仅作用于 write 系统调用，非磁盘空间。
防范 Bug 导致磁盘写满，核心不在单个系统调用限制，而在分层控制：文件系统配额兜底、运行时资源隔离（cgroups）、应用行为规范（日志策略）、外部可观测性（监控+告警）。ulimit -f 是个容易误解的工具，慎用勿依赖。
