对象存储的缓存节点，/cache 是 4T 的云盘，用 mkfs.ext4 默认参数格式化后挂上，写了大概一天，目录里出现 No space left on device，df -h 显示只用了 1.9T，df -i 也很正常。
这类报错背后常见的原因有几处，逐个排除就行。文件系统没开 64bit 特性，单个块组和单个目录的容量被限制在 2T 量级；mkfs 用的老版本 e2fsprogs 默认不启用 64bit，参数里也没显式打开；分区表是 MBR，分区本身先被卡在 2T 边界；上层用了一个巨型目录平铺所有文件，单个目录先撞到上限。
动手时先确认文件系统有没有 64bit 这个特性
dumpe2fs -h /dev/vdc1 | grep -i features然后把数据先挪到另一块盘
rsync -aHAX /cache/ /mnt/tmp/cache/再往下重新格式化并显式打开 64bit
mkfs.ext4 -O 64bit -m 1 /dev/vdc1剩下的就是按业务拆目录结构再导回数据
find /mnt/tmp/cache -maxdepth 1 -type d | head别只看报错消失，验证要多做一步。dumpe2fs 的输出里能看到 64bit，向 /cache 连续写入超过 2T 后 df 仍有余量，不再报 No space left。
补一句。已经写满的老文件系统没法就地打开 64bit，只能重建后迁数据；迁移前先确认备份可用，别把唯一副本挪来挪去。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。