Linux 运维避坑指南：根目录爆满了怎么办？从字节换算到日志治理-优快云博客

在日常维护 Linux 服务器时，我们经常会遇到这样的场景：系统报错提示“磁盘空间不足”，执行 ls -l 看到一长串数字，或者 df -mh 发现根目录挂载点进度条已经变红（98% 以上）。

今天就以一次真实的排查过程为例，分享如何科学地处理大文件与日志。

一、识破数字：ls -l 里的 30482163185 到底有多大？

当你执行 ls -l 时，文件大小默认是以 Byte（字节） 为单位显示的。对于上百亿的数字，肉眼很难直观判断。

1. 快速换算公式

计算机系统中，单位换算通常遵循 $1024$ 进制：

$$30482163185 \text{ B} \div 1024 \div 1024 \div 1024 \approx 28.39 \text{ GiB}$$

也就是说，这个文件占用了约 28.4 GB 的空间。

2. 懒人必备命令

与其手动计算，不如在执行命令时加个 -h 参数（human-readable）：

ls -lh：直接显示为 29G。
du -sh *：查看当前目录下各个文件/文件夹的总大小。

二、深度排查：为什么我的根目录（/）满了？

很多时候，我们发现 /opt 或 /var 下有大文件，但并没有意识到它们属于哪个分区。

1. 寻找挂载点逻辑

通过 df -mh 命令可以观察磁盘分布。如果你的输出显示 / 分区大小为 50G，而 /home 分区有 4.5T，那么：

如果 /opt 没有独立出现在“挂载点”一列，它就物理属于根目录（/）分区。
当 /opt 下产生一个 28G 的日志时，仅有 50G 的根目录就会迅速告急（使用率直冲 98%）。

2. 空间不平衡的痛

这种“贫富差距”巨大的分区架构（根目录小、Home 目录大）在 CentOS 等系统中很常见。最佳实践是：将数据、日志、大型应用安装在 /home 下，或者在 /home 创建目录并软链接到根目录。

三、治理长大的 nohup 日志：四种方案

程序运行产生的 1.log 越来越大，直接删掉文件往往无法释放磁盘（因为进程仍持有文件句柄）。我们需要更优雅的处理方式：

方案 A：在线清理（急救）

不需要停止程序，直接清空内容：

Bash

# 推荐方式，将文件置为 0 字节
true > 1.log
# 或者
cat /dev/null > 1.log

方案 B：重定向至“富裕”分区（治本）

既然 /home 有 4.4T 空间，为何不把日志放过去？

Bash

# 启动时指定路径
nohup ./start.sh > /home/logs/1.log 2>&1 &

方案 C：使用 logrotate（自动化）

利用 Linux 自带的 logrotate 工具进行日志滚动。创建配置文件 /etc/logrotate.d/myapp：

Plaintext

/opt/app/1.log {
    daily
    rotate 5
    copytruncate    # 关键：先复制再清空，适合 nohup 进程
    compress
    missingok
}

方案 D：实时切分（进阶）

利用 rotatelogs 等工具，在产生日志时就按大小或时间切分，避免单个大文件的出现。

四、总结

多用 -h 参数：无论是 ls -lh 还是 df -h，直观的数据能帮你更快决策。
警惕根目录空间：核心系统分区一旦爆满，可能导致 SSH 无法登录、数据库损坏等严重后果。
日志必须治理：任何通过 nohup 启动的服务，都必须考虑日志清理或切分策略。