Linux的常用指令--df--du

作为一个Linux内核驱动开发者，尤其是做RV1126b这类嵌入式开发板调试时，你一定遇到过这种“致命报错”：驱动编译好的.ko文件无法加载，提示 No space left on device；或者开发板日志打印一半突然停了，排查半天发现是根文件系统被占满了。这时候，单靠一个命令找不到问题根源——你需要 df 和 du 这对“磁盘空间排查搭档”：df负责“看全局”（哪个分区满了），du负责“找细节”（哪个文件/目录占了空间），两者配合才能快速定位磁盘空间问题。

在我看来，df就像嵌入式开发板的“磁盘体检仪”，能一眼看清所有分区的总容量、已用空间、可用空间；而du就像“空间侦探”，能精准定位到吃满磁盘的大文件/目录。内核驱动开发中，不管是根文件系统满导致驱动加载失败，还是/tmp分区满导致设备树解析出错，这对搭档都是必用工具。

先搞懂：df——查看文件系统整体空间（看全局）

df的核心作用是查看各个文件系统（分区）的整体空间使用情况，嵌入式开发中重点关注根分区（/）、/tmp（临时文件）、/usr（驱动库/编译产物）、/var（日志）这些分区。

1. 核心用法（嵌入式开发必备）

# 最常用：人类可读格式显示所有分区的空间（-h），并显示文件系统类型（-T）
df -hT

在RV1126b开发板上执行，输出大概是这样：

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4       1.8G  1.7G   50M  98% /          # 根分区快满了（98%），问题根源！
tmpfs          tmpfs     496M     0  496M   0% /dev/shm
/dev/mmcblk0p6 vfat       64M   12M   52M  19% /boot
tmpfs          tmpfs     496M   20K  496M   1% /tmp

从输出能立刻看出：根分区（/）使用率98%，这就是驱动加载失败的原因——没有空间写入驱动模块或日志了。

2. 嵌入式开发常用参数

再搞懂：du——查看文件/目录的具体大小（找细节）

df告诉你“哪个分区满了”，但不会告诉你“谁占了空间”；这时候需要du，它能递归统计文件/目录的大小，精准找到吃满磁盘的“元凶”（比如大日志、编译残留的.ko文件、core dump文件）。

1. 核心用法（嵌入式开发必备）

# 场景：根分区满了，先看根目录下各一级目录的大小（--max-depth=1），人类可读（-h）
du -h --max-depth=1 /

在RV1126b开发板上执行，输出大概是这样：

1.2G    /usr
400M    /var
50M     /root
10M     /etc
8M      /tmp

立刻看出：/usr（1.2G）和/var（400M）是占空间的大头，接下来逐层排查：

# 排查/var目录：看里面的子目录大小
du -h --max-depth=1 /var

# 发现/var/log占了350M，继续排查
du -h --max-depth=1 /var/log

# 最终找到：/var/log/kern.log（内核日志）占了300M——就是它吃满了根分区！

2. 嵌入式开发常用参数

核心场景：df+du配合排查嵌入式磁盘空间问题

以RV1126b驱动开发中“根分区满导致驱动加载失败”为例，完整排查流程：

步骤1：用df定位满的分区

df -hT /  # 只看根分区

输出：/dev/root ext4 1.8G 1.7G 50M 98% / 确认：根分区使用率98%，空间不足。

步骤2：用du找大目录（从根目录开始逐层排查）

# 一级目录汇总
du -h --max-depth=1 /

# 定位到/var/log大，继续排查
du -h --max-depth=1 /var/log

# 找到大日志文件kern.log
ls -lh /var/log/kern.log

步骤3：清理空间（驱动开发常用操作）

# 清空内核日志（保留文件，避免进程报错）
echo "" > /var/log/kern.log

# 删除旧的驱动模块
rm -rf /usr/lib/modules/6.1.0-rv1126b-old/*

# 删除core dump文件
rm -f /tmp/core.*

步骤4：验证（df确认空间释放）

df -h /

输出：/dev/root ext4 1.8G 1.4G 400M 78% / 空间恢复，驱动能正常加载了！

嵌入式开发中的“坑”：df和du结果不一致

有时候df显示分区满，但du统计的总大小远小于已用空间——这是因为文件被删除但进程还在占用（比如日志进程还在写已删除的kern.log），文件句柄没释放，空间没回收。

# 找占用已删除文件的进程
lsof | grep deleted

# 重启进程释放文件句柄
systemctl restart rsyslog

重启后再用df看，空间就会恢复。

总结

df和du是嵌入式驱动开发中排查磁盘空间的黄金搭档：

1. df看全局：用df -hT快速定位哪个分区（比如根分区）空间不足，用df -i排查inode满的问题；
2. du找细节：用du -h --max-depth=1逐层排查大目录，精准找到占空间的文件（日志、core dump、旧驱动）；
3. 避坑点：df和du结果不一致时，用lsof找占用已删除文件的进程，重启释放空间。

记住这对搭档的配合逻辑，再也不用为“开发板空间满了”而焦头烂额，能把更多时间花在驱动逻辑调试上~

df+du的大致用法就讲到这里，大家有什么在嵌入式开发中排查磁盘空间的经典坑或小技巧，欢迎在评论区交流~