如何扩展 Linux 中 ext4 文件系统的大小
一、问题出现的背景
我们通过docker部署的程序已经吃满了所挂载的磁盘，导致里面的服务由于磁盘空间的不足而不能正常提供服务。此时我们首先进行了物理扩容，直接在vdb上扩容到1000G。然后通过相关的命令查看磁盘使用情况：
root@ecs-3d7e-0306907:~# lsblk -l
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 100G 0 disk
vda1 252:1 0 1M 0 part
vda2 252:2 0 4G 0 part [SWAP]
vda3 252:3 0 96G 0 part /
vdb 252:16 0 1000G 0 disk /mnt/docker
root@ecs-3d7e-0306907:~# df -H
Filesystem Size Used Avail Use% Mounted on
udev 8.4G 0 8.4G 0% /dev
tmpfs 1.7G 6.1M 1.7G 1% /run
/dev/vda3 102G 94G 3.2G 97% /
tmpfs 8.4G 0 8.4G 0% /dev/shm
tmpfs 5.3M 8.2k 5.3M 1% /run/lock
tmpfs 8.4G 0 8.4G 0% /sys/fs/cgroup
/dev/vdb 422G 401G 0 100% /mnt/docker
tmpfs 1.7G 0 1.7G 0% /run/user/0
overlay 422G 401G 0 100% /mnt/docker/overlay2/f4169c8040f7feb83d501eb08901a6753f99c9de68babf7cd8eff84f99b50748/merged
overlay 422G 401G 0 100% /mnt/docker/overlay2/5d48d0049826fd94e029cfcf62f8565a8efa2e8dc8d72b8123a39193a1addd3c/merged
shm 68M 0 68M 0% /mnt/docker/containers/17375cd9fb8e587e75668417137be89ce9c75cebb4709cabf0bea0ba50db4325/mounts/shm
shm 68M 0 68M 0% /mnt/docker/containers/2dba5dfdc56a8497636a0a9977558d7576e11f923641f233a6cbde50f2e9261f/mounts/shm
overlay 422G 401G 0 100% /mnt/docker/overlay2/0bb14c24fba842c6dcecf384c0f606a2be7a5a73871a59a1f0856969dbfd9e42/merged
shm 68M 0 68M 0% /mnt/docker/containers/39aa71287742e6179f605c74a7ff25d3c3deaf2c346b64e9e5099c4d203fe085/mounts/shm
overlay 422G 401G 0 100% /mnt/docker/overlay2/d1aff1baf515b785ef4e0c94579bc48d9f052af95695085afc3ad79590f0c216/merged
shm 68M 0 68M 0% /mnt/docker/containers/528d442ffaeefe5e1ce16a4ca44c6fa4e2d554a6dc69940fb7cc1ce068b0ad28/mounts/shm
通过lsblk -l 命令可以看出我们的扩容是成功的vdb已经有1000G了，可是通过df -H 查看使用情况时发现/mnt/docker挂载的盘符还是400多G，且已经没有使用空间了。
二、问题解决
df 显示的是文件系统的空间使用情况，而 lsblk 显示的是物理磁盘的分区结构。可以使用 fdisk查看磁盘的分区情况，确保没有未分配的磁盘空间。
root@ecs-3d7e-0306907:~# sudo fdisk -l
Disk /dev/vda: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: BEE1D62D-305F-4BC3-8DD7-B4AC6AE35634
Device Start End Sectors Size Type
/dev/vda1 2048 4095 2048 1M BIOS boot
/dev/vda2 4096 8392703 8388608 4G Linux swap
/dev/vda3 8392704 209715166 201322463 96G Linux filesystem
Disk /dev/vdb: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
磁盘 /dev/vdb 的情况，总大小是 1000 GiB，而分区数是0。这说明整个磁盘 /dev/vdb 并没有被分区，而是被直接格式化并挂载使用。lsblk 报 /dev/vdb 是 1000G，df -H 显示 /dev/vdb 是 422G。这是一个很大的差距，表明这个文件系统不是完整使用了 1000G，很可能是因为以下两个原因：
（1）xfs 文件系统 XFS 文件系统在某些服务自动初始化挂载时，可能只使用了磁盘的一部分进行文件系统创建。即如果是 XFS，默认可能没有使用整块磁盘。
（2）文件系统只初始化了部分磁盘容量。
root@ecs-3d7e-0306907:~# df -Th /mnt/docker
Filesystem Type Size Used Avail Use% Mounted on
/dev/vdb ext4 393G 373G 0 100% /mnt/docker
/mnt/docker 上使用的是 ext4 文件系统，而文件系统的总大小为 393G，其中已使用 373G，剩余 0（已满）。这说明文件系统并未使用整块磁盘（1000G），而是只用了大约 393G 的空间。ext4 文件系统可能只格式化了大约 393G 的空间，而不是整块 1000G 的磁盘空间。
如果扩展到使用整个 1000G 的磁盘空间操作步骤如下：
（1）检查磁盘分区表
从上面的图片可以看出/dev/vdb的分区是唯一的没有被其他分区占用，所以才可以通过 resize2fs 来扩展 ext4 文件系统使用所有可用的空间。
（2）卸载 /mnt/docker 文件系统
# 注需要提前关闭所有docker服务，停止docker
# docker stop $(docker ps -a)
# systemctl disable docker
# 只有这样才能确保能卸载
sudo umount /mnt/docker
（3）使用 resize2fs 命令来扩展文件系统，使其使用整个磁盘空间
sudo resize2fs /dev/vdb
（4）挂载文件系统
sudo mount /dev/vdb /mnt/docker
（5）检查扩展结果
df -Th /mnt/docker
经过上面的所有步骤得出下面的结果：
root@ecs-3d7e-0306907:~# lsblk -l
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 100G 0 disk
vda1 252:1 0 1M 0 part
vda2 252:2 0 4G 0 part [SWAP]
vda3 252:3 0 96G 0 part /
vdb 252:16 0 1000G 0 disk /mnt/docker
root@ecs-3d7e-0306907:~# df -H
Filesystem Size Used Avail Use% Mounted on
udev 8.4G 0 8.4G 0% /dev
tmpfs 1.7G 6.2M 1.7G 1% /run
/dev/vda3 102G 94G 3.2G 97% /
tmpfs 8.4G 0 8.4G 0% /dev/shm
tmpfs 5.3M 8.2k 5.3M 1% /run/lock
tmpfs 8.4G 0 8.4G 0% /sys/fs/cgroup
tmpfs 1.7G 0 1.7G 0% /run/user/0
/dev/vdb 1.1T 401G 602G 40% /mnt/docker
overlay 1.1T 401G 602G 40% /mnt/docker/overlay2/a3919bcc4553e69220a03661d6079a6b79d0ba307cfec2057cffc04e0c3b76fe/merged
overlay 1.1T 401G 602G 40% /mnt/docker/overlay2/5d48d0049826fd94e029cfcf62f8565a8efa2e8dc8d72b8123a39193a1addd3c/merged
overlay 1.1T 401G 602G 40% /mnt/docker/overlay2/f4169c8040f7feb83d501eb08901a6753f99c9de68babf7cd8eff84f99b50748/merged
overlay 1.1T 401G 602G 40% /mnt/docker/overlay2/0bb14c24fba842c6dcecf384c0f606a2be7a5a73871a59a1f0856969dbfd9e42/merged
shm 68M 0 68M 0% /mnt/docker/containers/cf1e97c030062418d343710afdf4e7e534dbc37c014d4a46c0d662825fb6d54b/mounts/shm
shm 68M 0 68M 0% /mnt/docker/containers/17375cd9fb8e587e75668417137be89ce9c75cebb4709cabf0bea0ba50db4325/mounts/shm
shm 68M 0 68M 0% /mnt/docker/containers/2dba5dfdc56a8497636a0a9977558d7576e11f923641f233a6cbde50f2e9261f/mounts/shm
shm 68M 0 68M 0% /mnt/docker/containers/39aa71287742e6179f605c74a7ff25d3c3deaf2c346b64e9e5099c4d203fe085/mounts/shm
overlay 1.1T 401G 602G 40% /mnt/docker/overlay2/8fb1ed655aa00c3c2047dd3c9501f4d1c977c71d68636909203716b52722b4c1/merged
shm 68M 0 68M 0% /mnt/docker/containers/b3e7d3dcf9f2c1655c59c33edc9f8f491a50c48e7560900460706f54df10154c/mounts/shm