前言：别慌，磁盘容量不对齐常有事儿

说实话，df -h 和 lsblk kan起来像两只不合拍的鸽子。

一个说文件系统占了多少，一个说硬盘到底有多大。

结果你打开终端，发现两者数字相差天壤之别——这时候心里会想，哎呀，我的服务器要崩溃了？

其实这种情况完全Ke以被“咱就是说”一步步拆解。

lsblk——它只管硬件层面的块设备。

它列出 /dev/sda、/dev/vdb 那些“砖头”，大小直接来源于磁盘的物理容量或者云盘的配额。

所以你kan到的 215GB，往往是厂家在十进制下算出来的数字。

df -h——它只kan文件系统层面。

它统计的是挂载点上的 inode、预留空间、日志等占用后剩余的可用空间。

再加上 ext4/XFS 那些默认保留 5% 给 root 的“隐形”空间，数字自然会缩水。

① 磁盘扩容后忘记 文件系统。

② 分区没有占满整个磁盘，留白区域没人管。

③ 文件系统类型自带预留。

④ 隐藏的大文件或损坏的 inode 把空间占满，却不在 du 里显现。

我们来聊聊Zui近一次手撕这类问题的经历。

服务器上执行 lsblk

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda    8:0    0    40G  0 disk 
└─sda1 8:1    0     1G  0 part /boot
sdb    8:16   0   200G  0 disk 
└─sdb1 8:17   0   200G  0 part /var/lib/docker

但随后 df -h /var/lib/docker

# df -h /var/lib/docker
Filesystem      Size Used Avail Use% Mounted on
/dev/sdb        50G   35G   16G   ?? /var/lib/docker

?？这里明显不对啊！lsblk 明明是200G，df 却只给了50G。

# parted /dev/sdb print
Model: QEMU HARDDISK 
Disk /dev/sdb: 215GB
Sector size : 512B/512B
Partition Table: gpt
Number Start   End     Size    File system Name
1      .00B    .00B    .00B               primary
# ......
1      .00B    .00B    .00B               xfs       primary

kan起来分区Yi经占满全部容量，排除 “分区未扩容”。哈，这一步算是踩了个小坑——hen多人直接就卡在这里以为是分区问题。

# df -T /var/lib/docker
Filesystem     Type     Size Used Avail Use% Mounted on
/dev/sdb       xfs      ... ... ... ...

XFS 出场！记住 XFS 不会自己自动伸展，即使底层块设备Yi经变大，也需要手动喊它 “grow”。不对不对，我刚才写错了是要用 xfs_growfs 而不是 resize2fs。哈哈，这种小错误经常让人抓狂。

# xfs_growfs /var/lib/docker
meta-data=... isize=... agcount=... ... 
Data blocks = ...
...

Aha！一条命令搞定，无需下线停机。执行完再kankan：

# df -h /var/lib/docker
Filesystem      Size Used Avail Use% Mounted on
/dev/sdb        215G   35G  180G   ?? /var/lib/docker

现在两个命令显示一致啦！这就是“问题彻底解决”的那一刻——哈哈，你懂的，那种成就感简直比吃到辣条还爽！

步骤一： 确认分区Yi 到Zui大。 比如使用 parted /dev/sdx print.

步骤二： 执行 resize2fs /dev/sdxY.

提示： Ru果文件系统仍然只读，请先确保没有进程占用，然后 /sbin/e2fsck -f /dev/sdxY.

结果： 再跑 df -h, 大小马上跟上硬盘实际容量.

btrfs 天生支持在线增删子卷，用 btrfs filesystem resize max /mountpoint.

a btrfs 会自动利用新块，不需要额外操作，不过还是建议检查一下 .

btrfs 的 “保留空间” Ke以通过 btrfs property set -ts quota enabled true . 哈哈，这玩意儿太灵活了有点像魔法师。

CACHE 和 tmp 常常悄悄吃掉几 GB，却不会在 lsblk 上出现，因为它们根本不是块设备，而是挂在文件系统里的目录罢了。

所以当你kan到 df 显示Yi满，却 lsblk kan着宽裕时先检查一下以下路径：

/var/cache/*     — 包管理器缓存；

/tmp/*     — 临时文件；

/var/log/*     — 日志滚动不到位；

/home//.local/share/Trash/   — 垃圾箱。

。

找大文件： duf -x --max-depth=1 --exclude-path=/proc --exclude-path=/sys | sort -hr | head -n10 。 其实Zui直接的是： dfind . -size +10G | wc -l ; find . -size +10M | du -shx $. Ru果发现某目录异常庞大，那就可Neng是“幽灵文件”。 Ru果没有，那只Neng继续深挖。

检查 inode 使用率： . 若 inode Yi满，即使还有空间也会报 “No space left on device”。 这时候只Neng删掉无用的小文件或扩大 inode。

修复损坏 inode： xfs_repair -L /dev/sdxY 或 e2fsck –f –y /dev/sdxY . 不过要先卸载或进入 rescue 模式，否则风险太高。

#!/bin/bash
echo "=== 磁盘概览 ==="
lsblk | grep disk
echo "=== 文件系统使用 ==="
df -Th
echo "=== inode 使用 ==="
df -i
echo "=== 大于10G 文件 ==="
find / -type f -size +10G -exec du -sh {} \; | sort -hr | head
echo "=== 完成 ==="
# 用法：chmod +x check.sh && ./check.sh 
# 小提醒：Zui好在非生产时间跑。

©2026 Linux 运维随笔 | 保持好奇，继续探索 🚀