1月15号,很多团队刚做完年前最后一轮版本发布,说实话这时候最怕的不是新功能出bug,而是存量机器突然闹情绪。我今年遇到的第一波集中故障,全是磁盘相关的:根分区快写满了,备份盘挂载点不知什么时候掉了,还有一台机器因为 fstab 写错直接卡在启动阶段。趁着处理完这些问题的热乎劲,把 Linux 磁盘管理里最常用到的那一整套东西按实际干活顺序整理出来:查设备、分区分卷、格式化、挂载、排查空间、在线扩容。不是纯命令罗列,重点是讲清楚每一步为什么这么做,以及哪些坑是文档里不会写但我们肯定会踩到的。
先把目标定位一下:这篇内容适合刚接手服务器的新运维、经常要在 Linux 上处理数据盘的后端开发,也适合准备面试时想系统过一遍磁盘知识的人。看完之后面对一台陌生机器,你至少能安全地确认“这块盘是什么、能不能动、动了之后怎么恢复”。
1. 先搞清机器上有哪些盘和分区,再决定动不动刀
很多人一上来就 fdisk -l,看到 /dev/sdb 就直接分区,这种操作在空闲的测试机上没问题,在存量机器上就很容易出事。因为你看到的设备名并不是一个稳定标识,系统每次启动时对设备的枚举顺序可能变化,尤其是有多块同型号硬盘或虚拟化环境里挂载了多个磁盘的时候。
1.1 用 lsblk 一分钟看清设备树
我接手的每台机器,第一命令永远是 lsblk,而不是 fdisk。原因很简单,lsblk 输出非常直观,能直接展示磁盘、分区、挂载点的树状关系:
bash复制lsblk
典型输出是这样:
text复制NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 447.1G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 119.2G 0 part /
└─sda3 8:3 0 327.4G 0 part /home
sdb 8:16 0 3.7T 0 disk
└─sdb1 8:17 0 3.7T 0 part /data
如果加 -f 参数,还能额外显示文件系统类型和 UUID:
bash复制lsblk -f
这个参数非常关键。因为后面写 /etc/fstab 的时候既可以用设备路径,也可以用 UUID。而设备路径可能漂移,UUID 是文件系统创建时生成的唯一标识,稳定性高得多。
当机器使用 NVMe 盘时,设备名会变成 nvme0n1、nvme0n2 这种形式,分区后缀是 p1、p2。比如:
text复制nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
└─nvme0n1p2 259:2 0 931G 0 part /
虚拟化环境里则可能是 vda、vdb,云盘默认也是这个套路。所以别把 sda 当成永远不变的名字,它只是“当时识别到的某个设备”。
1.2 设备别名的正确查看方式
想要精确区分物理盘,最稳妥的做法是查看 /dev/disk/by-id/ 或 /dev/disk/by-uuid/ 目录:
bash复制ls -l /dev/disk/by-id/
这里能看到硬盘的厂商、型号、序列号与设备名的对应关系。生产环境里做数据盘迁移时,不要靠“我猜 sdb 是那块 4T 的盘”,而应该先确认序列号或 WWN。多盘机器上搞错目标盘,后果是不可逆的。
另外还需要确认系统盘和数据盘的边界。我见过有人把云主机里的系统盘当作空数据盘重新格式化,发现时所有业务代码已经一起消失了。建议先用 lsblk 看挂载点,凡是挂着 /、/boot、/var 的盘,都不要当作可随意初始化的对象。
1.3 用 df 和 du 分别判断“文件系统满没满”和“目录占了多少”
df 和 du 是一对经常被混淆的命令。df 是站在文件系统角度,统计整个分区的已用空间、剩余空间、挂载点;du 则是站在目录树角度,统计每个目录实际占用。
bash复制df -hT
du -sh /data/*
两者统计结果不一致是非常正常的。原因包括:删除文件但进程仍然占用、日志被 truncate 之后文件系统没释放、以及挂载点下层存在被覆盖的旧目录。日常排查要学会两条腿走路,先用 df 定位到哪个分区满了,再用 du 顺着目录往下找大文件。
提示:无论多急,都不要在没看过
df -h和lsblk -f的情况下直接执行 mkfs、fdisk 这类破坏性命令。先花两分钟看清现状,能避免绝大多数误操作。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
