必须禁用NFS、APFS加密卷、Docker overlay2、FAT32/exFAT等不支持原子操作或低效文件系统；缓存路径须部署于独立NVMe/SATA SSD的XFS（推荐，挂载参数noatime,inode64）或调优后ext4分区，权限为nginx:nginx，禁用SELinux/AppArmor，并预留≥20%磁盘空间。
要防止因文件系统格式不兼容引发的大缓存读写瓶颈，核心不是“选对格式”，而是主动规避低效或不支持原子操作的文件系统，并配合 Nginx 缓存路径的物理部署策略。Nginx 本身不校验文件系统特性，但它的缓存行为（尤其是 use_temp_path=off、proxy_cache_lock、rename() 调用）在 NFS、APFS 加密卷、Docker overlay 等非本地 POSIX 文件系统上极易失效或性能骤降。
必须禁用的文件系统类型
以下类型一律不得用于 proxy_cache_path 目录：
-
NFS 共享卷：不保证
rename()原子性，缓存写入可能静默失败，返回 502 或缓存错乱 -
APFS 加密卷（macOS）：内核层加密开销大，小文件随机读写延迟高，且
openat()性能不稳定 -
Docker 默认 overlay2 卷：多层写时 copy-on-write 机制导致元数据膨胀，
keys_zone查找变慢，cache manager清理卡顿 - FAT32/exFAT：无 inode、无硬链接支持，Nginx 缓存依赖的文件锁与哈希目录结构无法正常工作
推荐且需正确挂载的文件系统
仅限本地块设备，首选 XFS（生产环境），次选 ext4（需调优）：
-
XFS（强烈推荐）：
– 挂载参数加noatime,inode64,logbufs=8,logbsize=256k，降低日志压力与 inode 查找延迟
– 支持大目录、高效扩展，对百万级小缓存文件友好 -
ext4（可接受）：
– 必须启用dir_index和extent特性（mkfs.ext4 -O dir_index,extent）
– 挂载加noatime,nobarrier（若磁盘有掉电保护）
缓存路径部署硬性要求
不光看格式，更要看物理位置和权限控制：
-
独立 NVMe 或 SATA SSD 分区：缓存目录必须独占一块物理盘（如
/dev/nvme0n1p3），避免与日志、数据库共盘争 I/O - 禁止软链接或 bind mount 指向其他文件系统：Nginx 会按最终挂载点判断，软链绕不过底层限制
-
目录权限为
nginx:nginx，且禁用 SELinux/AppArmor 干预：否则open()或unlink()可能被拦截，表现为缓存写入缓慢或失败 -
预留 ≥20% 磁盘空间：XFS 在空间不足时元数据分配退化严重，
cache manager清理效率断崖式下降
验证是否生效的关键检查项
配置后必须逐项确认，不能只看 Nginx 启动成功：
- 运行
findmnt -t xfs /data/nginx/cache（或对应路径），确保输出显示真实挂载点及文件系统类型 - 执行
stat /data/nginx/cache，确认File: “/data/nginx/cache”下的Device:字段与df -T /data/nginx/cache一致 - 观察
nginx -t && nginx -s reload后 error.log 是否出现rename() failed (18: Invalid cross-device link)—— 出现即说明use_temp_path=off失效，存在跨文件系统路径 - 压测时用
iostat -dx 1观察await和%util，若await > 20ms且%util ≈ 100%，大概率是文件系统或硬件瓶颈，而非 Nginx 配置问题
