ext4预留空间是为root用户保留的磁盘缓冲区，默认5%以保障SSH、日志等关键服务在磁盘趋满时仍可应急写入；该值可通过tune2fs -m调整，根分区严禁设为0%，数据盘可酌情降至0.5%～4%。
ext4预留空间是啥，为什么默认5%
ext4文件系统默认会为root用户预留5%的磁盘空间，目的是防止普通用户写满磁盘导致系统无法运行（比如日志、SSH登录、关键进程崩溃恢复等）。这个值不是硬编码，而是通过tune2fs可调的参数，本质是给root保留一个“安全缓冲区”。
但对纯数据盘、NAS共享卷、Docker数据卷这类场景，这5%就是实打实浪费的容量——尤其在几十TB的盘上，可能意味着几百GB不可用。
用tune2fs把预留空间设为0%是否安全
可以设为0%，但必须确认使用场景：如果该分区**不承载系统关键服务、不运行sshd/syslog/cron等依赖磁盘写入的守护进程、且有外部监控/告警机制防止写满**，那设为0%没有问题。生产系统盘（如/或/var）不建议动。
操作前务必确认目标设备路径（比如/dev/sdb1），别错选根分区：
tune2fs -m 0 /dev/sdb1
执行后立即生效，无需重启或卸载。可用dumpe2fs -h /dev/sdb1 | grep "Reserved block count"验证是否归零。
- 若提示
Permission denied，说明没用root权限，加sudo - 若提示
Device is mounted，ext4允许在线修改预留比例，不用umount（这是常见误解） - 修改后
df -h显示的“Available”值会立刻变大，但已占用空间不变
预留空间改小后，root还能写满吗
能。设为0%只是取消“强制保留”，不代表root失去写权限。root始终可以写满整个分区，哪怕只剩1字节——区别在于：原来留5%时，普通用户最多用到95%，root能额外用那5%；现在0%后，普通用户理论上也能冲到100%，root不再有专属缓冲。
所以真正风险点是：当磁盘被普通用户/应用写到99%+时，系统服务可能开始异常（例如journald拒绝写日志、systemd单元失败）。这不是预留空间本身的问题，而是缺乏容量水位管控。
- 建议配合
df -h巡检或inotifywait监听/proc/mounts变化做告警 - 若用LVM，可在LV层面配thin pool自动扩展，比依赖ext4预留更可控
-
tune2fs -m 1是折中方案：留1%给root，释放4%，兼顾安全与空间
其他影响和容易踩的坑
预留空间调整不影响inode分配、不改变目录结构、不触发rebalance，纯粹是块计数器变更。但要注意几个隐性坑：
- 某些云平台（如AWS EBS）挂载后自动运行
e2fsck或tune2fs脚本，可能覆盖你的设置，需检查启动脚本 - Docker overlay2存储驱动在ext4上运行时，若底层盘预留为0%且无配额限制，容器日志可能瞬间撑爆磁盘
-
resize2fs扩容文件系统后，预留比例会继承原值，不是重置为5%，这点常被忽略 - 备份工具（如
rsync或borg）不感知预留空间，它们看到的是总容量减去已用，不会主动避开那5%
最麻烦的情况其实是：你改了-m 0，结果发现应用日志轮转配置错了，一夜之间填满磁盘，而监控没覆盖该盘——这时候才意识到，预留空间不是万能锁，只是最后一道低配保险丝。
