磁盘满了这件事基本每个搞过 Linux 运维的人都躲不掉。我上个月刚处理完一台 CentOS 老服务器的根分区告警使用率飙到 97%监控连续报警业务日志写不进去。这次扩容过程踩了不少坑也把几年前积累的一些经验重新捡了起来索性整理成这篇记录把 CentOS 挂载、分区、扩容的完整套路讲清楚。这篇文章适合刚接触 Linux 的新手也适合那些平时不怎么碰磁盘操作、一遇到扩容就紧张的老运维。我会把 LVM 扩容、裸设备扩容、新盘挂载、fstab 持久化、常见坑和排查思路都过一遍这些都是实际生产环境里真正用得到的东西。1. 开工前先摸底分区结构决定了扩容路线1.1 先看磁盘使用率和文件系统类型拿到一台磁盘告警的服务器别急着敲fdisk先按顺序做三件事看使用率、看挂载结构、看文件系统类型。这三步的结果直接决定你后面用哪套扩容方案。df -h lsblk blkiddf -h用来确认哪个分区满了lsblk看整个磁盘的树形结构和挂载点blkid看设备 UUID 和文件系统类型。这里特别要留意文件系统类型因为 CentOS 7 默认用的是 xfsCentOS 6 及以前常用 ext4两种文件系统扩容时用的命令完全不一样。xfs 只能扩大不能缩小ext4 虽然能缩但风险高生产环境没人敢随便缩。我处理过一台云服务器根分区就是 xfs同事直接拿 ext4 的resize2fs命令去扩当场报错Bad magic number in super-block其实就是文件系统类型不匹配。后面排查时还发现设备名也被认错了整个操作完全没按实际情况来。所以说开工前先确认这三个信息比什么都重要。1.2 分清 LVM 与裸设备扩容路线完全不同在 CentOS 里磁盘分区有两种常见的组织方式一种是直接用物理分区挂载比如/dev/sda1挂到/boot这种叫裸设备分区另一种是通过 LVM逻辑卷管理来管理比如/dev/mapper/centos-root挂到/云服务器和大部分物理机装系统时默认走的都是 LVM。判断方式很简单看/dev/mapper/路径就知道。如果df -h显示的是/dev/mapper/xxx-root说明根分区在 LVM 逻辑卷上如果显示的是/dev/sda1那就是普通分区。LVM 的扩容逻辑可以理解为物理硬盘是“原料仓”卷组是一个“资源池”逻辑卷是分配出去的“配额”。要扩容逻辑卷先往资源池里加原料新磁盘或新分区再把资源池的容量划拨给逻辑卷最后让文件系统感知到容量变化。裸设备的扩容就麻烦得多因为它没有中间这层资源池要么直接调分区大小要么只能迁移数据。我在实际工作中遇到的最大的坑就是很多人不确认分区结构上来就用 LVM 的命令去扩裸设备或者反过来用分区工具动 LVM 的物理卷。结果要么操作不生效要么在操作中途把系统搞崩。2. 场景一LVM 逻辑卷扩容最顺滑的路线2.1 新磁盘加入卷组从 pvcreate 到 lvextend假设你的 CentOS 是标准 LVM 安装现在加了块新磁盘/dev/sdb想把容量划给根分区完整操作分五步顺序不能乱。第一步确认新盘已被系统识别lsblk如果没有看到/dev/sdb可能是虚拟化平台的磁盘没有重新扫描可以执行echo - - - /sys/class/scsi_host/host0/scan或直接重启云服务器一般控制台挂载后就能看到。第二步把整块盘或某个分区初始化为物理卷pvcreate /dev/sdb如果要用整块盘做 PV不需要分区直接对磁盘初始化即可。但有些环境里更规范的做法是先分区再pvcreate /dev/sdb1这样后续如果要多分区管理会更清晰。第三步把物理卷加入卷组。先确认卷组名vgsCentOS 默认卷组名一般是centos或cl然后执行vgextend centos /dev/sdb第四步扩展逻辑卷。先看一下逻辑卷路径lvs比如逻辑卷是/dev/mapper/centos-root想把新盘全部空间加进去lvextend -l 100%FREE /dev/mapper/centos-root这里的-l 100%FREE表示把卷组剩余的所有空间都分配给该逻辑卷。如果只想加指定大小用-L 50G注意不能省略表示增加而不是扩充到某个绝对值。第五步调整文件系统大小。这是最关键的一步xfs 和 ext4 命令不同# xfs 文件系统 xfs_growfs /dev/mapper/centos-root # ext4 文件系统 resize2fs /dev/mapper/centos-root执行完再跑一下df -h容量就变了。2.2 虚拟机磁盘扩容后再分区建 PV如果你用的是 VMware 或 VirtualBox扩容通常不是加新盘而是在虚拟化层面把原有虚拟磁盘调大。这种情况下原盘/dev/sda会多出一段未分配空间要把它利用起来。操作顺序是虚拟机设置中扩大磁盘容量 - 操作系统识别新空间 - 创建新分区 - 建 PV - 加入卷组 - 扩展逻辑卷 - grow 文件系统。系统里先确认空间是否被识别lsblk如果显示的大小没变执行下面的命令重新扫描 SCSI 设备echo 1 /sys/class/scsi_device/0:0:0:0/device/rescan然后创建分区。这里推荐用parted因为它既能处理 MBR也能处理 GPT而且用起来更直观。假设新空间在/dev/sda的剩余部分parted /dev/sda # 进入交互界面后执行 print free mkpart primary ext4 40GB 100GB quit分区号可能会是/dev/sda3取决于原来有几个分区创建后让它重新读取分区表也可以重启或者执行partprobe /dev/sda。接着按 LVM 流程走pvcreate /dev/sda3 vgextend centos /dev/sda3 lvextend -l 100%FREE /dev/mapper/centos-root xfs_growfs /dev/mapper/centos-root这套操作是完全在线进行的不影响业务。不过有个细节要提醒如果你用的是 MBR 分区表主分区最多只能建四个新的扩展分区请确保没有超过这个限制否则分区表会拒绝写入。2.3 在线扩容为什么必须 lvextend 和 grow 命令配合我见过不少新手只做lvextend不去执行文件系统扩大的操作结果df -h里看到的容量根本没变化于是怀疑自己操作失败。其实逻辑卷层面已经变大了但文件系统还没有被“撑”到新的大小。这里解释一下底层逻辑逻辑卷扩容只是改变了逻辑卷设备的块设备大小而文件系统是在块设备之上维护自己的元数据和空间管理信息。如果不主动让文件系统去感知新的大小它依然以旧尺寸工作。xfs_growfs和resize2fs就是干这个活的而且它们都支持在线扩容不用卸载分区。实际操作中我建议先搞清楚自己的文件系统再动手别一上来就resize2fs。xfs 用resize2fs会直接报错ext4 用xfs_growfs同样不行两个工具互不兼容。3. 场景二非 LVM 裸设备分区的扩容3.1 裸设备扩容为什么让人头大如果你的磁盘没有走 LVM比如/dev/sdb1直接挂载到某个目录扩容的复杂度会立刻上升。裸设备的问题在于每个分区的大小受限于它后面的相邻空间如果相邻空间已经被占用你没办法“中间插一脚”把它扩大。更麻烦的是有些服务器的根分区/也在裸设备上它后面紧跟着的就是 swap 分区两边互不相让想扩根分区就不得不把 swap 挪走整体操作风险极高。在生产环境我一般不建议动裸设备的现有分区结构除非你有完整的备份和充分的维护窗口。3.2 通过 parted 调整分区大小的实操流程如果确认可以离线操作或者分区后面确实有可用空间可以用parted去调整分区大小。先看一下当前分区布局parted /dev/sdb print free假设输出显示/dev/sdb1后面有一段 Free Space就用 resizepart 指令来扩大parted /dev/sdb resizepart 1 100%这里的1是分区号100%表示扩展到磁盘末尾。执行完成后让内核重新读取分区表partprobe /dev/sdb然后根据文件系统类型在线扩大# xfs xfs_growfs /mount/point # ext4 resize2fs /dev/sdb1如果分区后面是已分配的空间没有空闲区域那就不是单纯调整分区大小能解决的了只能把后面的分区删除重建数据另存或者放弃裸设备方案迁移到 LVM。这里强烈建议新规划的服务器一律用 LVM。裸设备一时省事以后扩容会加倍还回来。3.3 实在没空间可扩时的补救方案还有一种常见场景磁盘本身已经满了而且底层虚拟磁盘也没法在系统运行时扩大连/都写不进新文件。这时候只能走临时挂盘的方案。操作思路是挂载一块新磁盘到系统里把它格式化为目标文件系统然后做数据迁移或目录绑定。具体做法可以参考下面第 4 节的挂载流程。如果只是想快速腾空间可以把大文件目录迁移到新盘上再用 bind mount 把新盘的目录映射回原路径对用户无感知mkdir -p /data/newdisk mount /dev/sdc1 /data/newdisk rsync -av /var/lib/mysql/ /data/newdisk/ mount --bind /data/newdisk /var/lib/mysql这种方式本质是换了个存储后端。但要注意bind mount 不是永久的需要写进/etc/fstab才能重启后保留。4. 新增数据盘的挂载全流程含 fstab 最佳实践4.1 格式化、挂载、持久化一条龙加数据盘和加根分区容量是两个概念。数据盘通常是独立分区或独立磁盘挂载到新目录逻辑上更清晰。流程如下第一步确认设备名并格式化为目标文件系统lsblk mkfs.xfs /dev/sdc这里用整块盘做文件系统不分区也是可以的但如果生产环境建议分区便于将来调整。格式化前一定想清楚设备名对不对mkfs是毁灭性操作写错盘符数据就没了。第二步创建挂载点并挂载mkdir -p /data mount /dev/sdc /data第三步确认挂载成功并设置开机自动挂载。先把 UUID 查出来blkid /dev/sdc然后把下面这行写入/etc/fstabUUID你的UUID值 /data xfs defaults 0 0写入前最好先备份一下/etc/fstabcp /etc/fstab /etc/fstab.bak第四步测试 fstab 是否正确mount -a df -h这一步是在不重启的情况下验证 fstab 的配置是否有误。如果mount -a报错说明配置有问题立即改正避免重启后系统进不去。4.2 为什么推荐用 UUID 而不是设备名挂载很多老教程会教你写/dev/sdc /data xfs defaults 0 0这在物理服务器上或许没问题但在云服务器和虚拟化环境里非常危险。设备名不稳定系统每次启动时设备的识别顺序可能不同原来/dev/sdc可能变成/dev/sdd结果就是挂载失败或者更糟挂错盘。blkid输出的 UUID 是文件系统创建时唯一生成的标识不会因为设备顺序变化而改变。因此 fstab 里优先用 UUID 挂载这是一个非常值得养成的好习惯。还有一个小细节fstab 的最后一列“dump”和“fsck”两项数据盘一般写0 0表示不参与 dump 备份和开机自动 fsck否则某些系统开机会因为 fsck 检查非 root 分区失败而卡在紧急模式。4.3 挂载参数 defaults 和 noatime 的选择defaults包含 rw、suid、dev、exec、auto、nouser、async 等选项是一组最常用的默认挂载参数。对一般数据盘来说没问题但对高 IO 负载的数据库或日志盘我会额外加noatime避免每次读取文件都更新访问时间戳减少不必要的磁盘写入。UUIDxxx /data xfs defaults,noatime 0 0如果是数据库目录还可以考虑barrier1xfs 默认开启或者nobarrier这种性能取向的调整但这不是通用建议建议按实际场景测试后再用。5. 常见问题与排查记录5.1 典型问题速查表现象大概率原因解决办法resize2fs报Bad magic number in super-block文件系统是 xfs用了 ext4 工具改用xfs_growfsdf -h没变化执行了 lvextend 但没执行 grow 文件系统按文件系统类型执行对应 grow 命令parted创建分区提示无法识别磁盘原本无分区表未初始化先mklabel gpt再分区fstab 写错导致开机进入 emergency mode挂载项有误或设备不存在输入 root 密码执行mount -o remount,rw /后修改 fstabmkfs报设备忙磁盘已被挂载使用先umount再格式化大于 2T 的盘无法使用fdisk分区MBR 分区表最大只支持 2T用parted切 GPT 分区表扩容后根分区容量仍在 100%可能有已删除但未释放的文件lsof | grep deleted排查并重启对应进程5.2 扩容实战中容易忽略的几个细节第一次给客户虚拟机扩容时我在parted里创建了分区结果系统里看不到新的分区名/dev/sda3。后来发现是内核还没有重新读取分区表执行partprobe后问题解决。这个细节现在看起来很基础但第一次遇到时真的会卡很久。还有一次是 fstab 里用了设备名挂载结果服务器重启后设备顺序变了系统直接进入了维护模式。当时是异地机房幸好可以远程进入紧急模式才把 fstab 改回来。从那以后我坚持所有 fstab 配置都使用 UUID。另一个常见问题是磁盘满了之后服务的表现往往不是“写不进去”那么直接。数据库可能一直报 read-only 表Java 应用可能卡在文件写入上不报错df -h一看才发现根分区 100%。下次如果你遇到服务无规律异常先看一眼磁盘使用率很多疑难杂症其实都是磁盘满导致的。5.3 检查文件系统是否真的扩容成功扩容完别急着收工做一次完整验证df -h pvs vgs lvs如果 pvs 里的物理卷容量正常vgs 里卷组容量变大了但逻辑卷没有变大说明lvextend没执行成功。如果逻辑卷变大了但df -h没变化说明 grow 文件系统那一步没做或者没生效。对 xfs 文件系统可以额外用xfs_info /mount/point查看文件系统的真实大小确认 grow 后的数据块数量和df输出一致。6. 结尾的一点个人经验这次扩容记录写下来最大的感受是 CentOS 磁盘管理核心就三件事确认现状、选择正确路线、按顺序执行。LVM 方案确实省心但前提是最初装系统时选了 LVM 布局。如果你手里还有老服务器用的是裸设备我建议找维护窗口做一次数据迁移把关键业务目录整合到 LVM 或者新盘上一劳永逸。最后再分享一个小技巧扩容前一定先看/etc/fstab内容确认现有挂载项是设备名还是 UUID。如果是设备名顺手改成 UUID别等出问题再后悔。磁盘操作虽然不像删库那么高危但一旦操作目标写错后果一样严重。每次执行mkfs、pvcreate、resizepart之前默念一遍“设备名对不对”能帮你省掉无数麻烦。
