半夜两点被监控吵醒登录一看/data分区使用率99%业务日志已经开始告警。云控制台明明已经把磁盘从500G扩到800G操作系统里df -h却纹丝不动——云盘扩了但分区没扩这是所有Linux运维都会遇到的事。我这次就用parted命令把GPT分区表的裸盘无损扩展完整走了一遍顺便把途中踩过的几个报错整理出来bad magic number、device busy这种高频问题基本可以照着抄答案。在动手之前先强调一句磁盘扩容的方法完全取决于磁盘的底子。LVM环境和裸分区环境的操作路径几乎是两条平行线网上大量教程默认你用的是LVM跟着做大概率在中间某个步骤就卡死了。所以我先带你花两分钟搞清现状再决定用哪套方案。1. 先搞清楚盘的情况LVM还是裸分区决定你走哪条路1.1 三条命令快速看清磁盘结构判断磁盘是不是LVM不需要什么花哨工具lsblk、df、blkid三件套就够了。生产环境登录上去第一件事就是跑这三个命令。lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT df -hT blkid输出大概长这样NAME SIZE TYPE FSTYPE MOUNTPOINT vda 100G disk ├─vda1 1G part xfs /boot └─vda2 99G part LVM2_mem / └─centos-root 99G lvm xfs / vdb 500G disk └─vdb1 500G part ext4 /data这里有两个关键信号根目录走的是LVM2_mem说明系统盘是LVM管理以后系统盘要扩容直接lvextend就行。/data挂载在vdb1上类型是ext4它上面没有LVM层这就是典型的裸分区。如果你看不懂lsblk的输出也没关系认准两个特征一是看TYPE列里有没有lvm二是看挂载路径有没有/dev/mapper/*。如果df -h里挂载点对应的是/dev/mapper/xxx那多半是LVM。1.2 LVM扩容和裸分区扩容的路线差异LVM扩容用一句话概括vgextend把新空间加进卷组lvextend把逻辑卷扩大resize2fs或xfs_growfs把文件系统撑满。全程在线操作几乎不需要停机也不需要动分区表风险天然小。裸分区扩容则完全不是一回事。磁盘尾部的新空间是无主之地你要把它归入现有分区唯一的合法路径是先删掉旧分区表项注意不是格式化、不是删数据再建一个起点相同、终点更靠后的新分区最后扩展文件系统。这里每一步都是在跟分区表打交道一旦起点写错数据全部作废。对比项LVM裸分区是否需要动分区表不需要需要先删后建是否支持在线操作支持风险很低支持但建议窗口期操作核心命令vgextend / lvextendparted / fdisk resize2fs主要风险卷组元数据损坏分区起点写错、中途断电适合场景虚拟化环境、系统盘物理机数据盘、云盘已扩容本文接下来的流程全部针对裸分区 GPT分区表 ext4/xfs文件系统的场景。如果你是LVM环境看到这里就可以去查lvextend的用法了不用往下浪费时间。需要补充一点我说的是删掉旧分区表项很多人听到删除分区就腿软这里先给你吃个定心丸。分区表只是磁盘上的一块索引信息真正的用户数据在分区内部的块设备上。删除分区表项时内核不会立刻去抹掉数据块所以只要不执行mkfs数据就还在。真正的风险点在于重建分区时起止扇区必须和原分区完全一致尤其是起始扇区必须分毫不差。2. parted无损的底层原理分区表、内核态和文件系统怎么配合2.1 分区表和文件系统是两层独立的东西用个最直白的类比来解释这个过程分区表是图书馆的检索目录文件系统是书架上的书。目录卡片只是告诉你物理位置在哪个区、哪个架你撕掉这张卡片书并不会从书架上消失重新写一张更宽的卡片把新书架范围也划进来书还是那些书。Linux里的层次关系是磁盘/dev/vdb └── 分区表GPT/MBR记录分区起点和终点 └── 分区/dev/vdb1一段连续的磁盘空间 └── 文件系统ext4/xfs负责组织文件数据扩容只改分区表不动文件系统的数据结构这是整个过程无损的基石。分区表改完之后文件系统看到的分区还是一块连续的设备只是容器变大了。这时候再让文件系统去利用新增的空间就是resize2fs或xfs_growfs干的事。2.2 为什么要用parted而不是fdisk早期fdisk对GPTGUID分区表支持不完善超过2TB的磁盘和GPT表基本只能用parted或gdisk。现在新版fdisk已经能处理GPT但parted在脚本化、非交互式分区操作上仍然更顺手而且它对GPT的打印、对齐处理比fdisk更直观。举个例子查看磁盘当前的空闲空间用parted一条命令就够parted /dev/vdb unit s print free输出里能看到每个分区的起始扇区、结束扇区、大小以及分区之间的空闲区。这些信息在扩容前必须记录下来尤其是原分区的起始扇区。我习惯用扇区单位而不是默认的KB/MB原因很简单扇区是分区表的最小单位用扇区记录起点可以有效避免四舍五入导致的对齐偏移。parted的resizepart子命令在3.2版本之后也支持直接调整分区终点如果你的parted版本较新理论上可以少走删了重建这一步。但实测下来在分区正在挂载的场景中resizepart有时会报Device or resource busy所以我更推荐标准的删除重建流程——虽然听起来吓人但步骤更可控也更容易排查问题。2.3 内核重读分区表partprobe、partx、kpartx的区别分区表改完了内核却还记着旧的分区布局。在Linux里修改分区表后必须让内核重新读取否则/dev/vdb1的大小还是旧的。常用工具有三个partprobeparted套件自带的命令用来通知内核重新读取分区表大多数场景够用。partx -u /dev/vdb主动更新某个磁盘的分区信息不重启也可以适合新增分区后使用。kpartx -a /dev/vdb适合设备映射场景比如LVM或多路径普通磁盘一般用不到。实际操作中如果是云主机磁盘在控制台扩容后、分区也改完后partprobe往往能直接生效。如果报了Re-reading the partition table failed通常是因为某个分区正被挂载使用或者内核不支持热重读。这种情况下最稳妥的办法是安排重启窗口不要硬扛着继续操作。2.4 为什么先删后建依然有理论风险既然无损是核心卖点这里必须把风险讲透免得你看完觉得自己天下无敌然后去搞生产库。最大的风险来自操作过程中的不确定性。删除分区表项、重建分区表项两步之间如果发生断电、误操作比如把起点输错、或者parted异常退出重建出来的分区可能和原来对不上。起点差一个扇区整个文件系统就废了什么rescue工具都不一定能救回来。其次是内核状态的不一致。分区正挂载在/data上你却把它的分区表项删了内核虽然还持有旧的文件系统句柄但分区表层面已经查无此分区这时候如果其他进程对这块盘做扫描或重读后果很难预料。所以我在生产环境执行这套流程前底线是必须满足至少一项云厂商快照已创建并在有效期内有文件级别的完整备份rsync或备份系统至少抄录了原分区起始扇区和结束扇区并保留parted print输出。满足这些条件操作才有底气。3. 实战/data从500G无损扩到800G的完整操作3.1 操作前要做的准备和记录场景演示一台云主机/dev/vdb是数据盘GPT分区表只有一个分区/dev/vdb1ext4文件系统挂载在/data。云控制台已经把磁盘从500G扩容到800G但系统里还没变。目标把/data无损扩展到800G。先把当前状态完整记录下来df -hT /data parted /dev/vdb unit s print free记下输出中的关键信息比如Number Start End Size File system Name Flags 1 2048s 975175679s 975173632s ext4 primary这里2048s就是原分区的起始扇区975175679s是结束扇区。删掉重建时起点必须写2048s终点则一直延伸到新的磁盘末尾。顺手确认一下文件系统类型别等到resize完发现命令用错了blkid /dev/vdb1输出里如果看到TYPEext4后面就走resize2fs路线如果看到TYPExfs就得用xfs_growfs。这两条命令互相不能混用混用的结果就是报错我在下一章详细说。3.2 用parted删除并重建分区表项正式操作前我建议先卸载/data。如果业务不允许卸载可以尝试在线操作但必须在低峰期执行并确保前面的备份条件都满足。umount /data然后操作分区表parted /dev/vdb unit s print free # 确认当前分区起点例如 2048s parted /dev/vdb rm 1 # 删除分区1此时数据没有丢只是分区表项被删掉了 parted /dev/vdb mkpart primary ext4 2048s 100% # 重建分区1起点必须写原来的2048s终点写100%用尽磁盘尾部的所有空间这里有几个细节值得展开第一mkpart的第三个参数ext4并不是真正去格式化文件系统它只是给GPT分区表设置一个分区类型标签。如果你用的是xfs文件系统这里写ext4也没有关系最终识别文件系统类型的是分区内的超级块而不是这个标签。但为了让分区表看着整洁建议跟真实文件系统保持一致。第二终点为什么写100%而不是具体的扇区数因为磁盘已经扩容到800G我们并不关心实际尾部扇区值是多少直接让parted帮你算简单又不容易错。parted对100%的理解是磁盘的最后一个可用扇区不会越界。第三如果parted提示Warning: The existing disk label on /dev/vdb will be destroyed不要慌这是它在提醒你要动分区表了。输入Yes继续。重建完分区让内核重新读取分区表partprobe /dev/vdb此时lsblk里应该能看到/dev/vdb1的容量已经变成800G了但文件系统还是旧的500G。3.3 文件系统扩展resize2fs还是xfs_growfs分区表已经扩大现在轮到文件系统层。先检查一下文件系统健康状况这步不能跳e2fsck -f /dev/vdb1-f是强制检查即使文件系统看起来干净也执行一遍。这一步能提前发现分区重建是否影响了文件系统结构。检查完没有error信息就可以扩展了。ext4文件系统扩展resize2fs /dev/vdb1xfs文件系统扩展mount /dev/vdb1 /data xfs_growfs /data注意这两者的区别resize2fs可以在卸载状态下操作也可以在挂载状态下在线扩容xfs_growfs则必须在挂载状态下执行因为它要挂载点作为参数。对于xfs操作流程是先mount回来再执行xfs_growfs。重新挂载并验证mount /dev/vdb1 /data df -hT /data不出意外/data的容量已经从500G变成800G文件数据完好无损。3.4 验证数据完整性和挂载配置扩容完成后别急着庆祝还要做三件事第一抽查数据完整性。随便进/data下几个目录看看文件能不能正常读写权限有没有变。如果文件系统里有数据库或中间件让业务方做一次基本的功能验证。第二确认/etc/fstab里的挂载配置。如果你之前用的是/dev/vdb1这种设备名路径建议改成UUID方式否则下次重启如果设备名变化比如从vdb变成vdc系统会直接挂载失败进入emergency模式。blkid /dev/vdb1 # 输出类似 UUIDabc123-xxxx-xxxx把/etc/fstab里的/dev/vdb1替换成UUIDabc123-xxxx-xxxx然后mount -a验证一下配置无误。第三重新检查一遍系统监控。扩容后磁盘剩余空间变大之前的告警会自动恢复但要注意确认监控采集本身没被磁盘空间打满影响。4. 常见报错排查手册每个坑我都替你先踩了这一章直接上干货按报错信息排列每条给出原因分析和处理方法。我把这些年踩过的坑和身边同事遇到过的案例集中在这里遇到问题先对照查。4.1 Device or resource busy这是删分区或partprobe时最常遇到的报错形式可能是Error: Partition(s) 1 on /dev/vdb have been written, but we have been unable to inform the kernel of the change或者parted直接拒绝操作Error: Partition /dev/vdb1 is being used. Are you sure you want to continue?原因很简单分区正在被挂载内核不允许你动它。处理办法首选umount /data如果umount的时候提示target is busy说明有进程还在用/data用下面的命令揪出来fuser -v -m /data看到PID后和业务方确认能不能停能停就kill不能停就说明这台机器不能离线窗口操作建议先别强行搞等流量低谷再处理。4.2 Re-reading the partition table failedpartprobe报这个错通常有两种情况一是内核不支持在线重读二是设备正忙。如果umount不现实先看看dmesg尾部有没有I/O错误排除磁盘硬件问题。我碰到过一种特殊情况云主机磁盘扩容后控制台端已经生效但实例内SCSI设备没有重新扫描新容量。这种情况可以试试echo 1 /sys/class/block/vdb/device/rescan或者部分云平台支持在控制台重新扫描磁盘。如果都不行最稳妥的还是重启一次。重启后内核重新枚举设备新容量必然生效。4.3 resize2fs: Bad magic number in super-block这个报错出现时大概率是文件系统类型判断错了。你以为它是ext4实际它是xfs或者反过来。解决办法就是先用blkid确认类型然后用对应的命令扩展。resize2fs: Bad magic number in super-block while trying to open /dev/vdb1出现这个不要慌不是数据坏了只是工具用错了。查一下blkid /dev/vdb1如果是xfs改用xfs_growfs /data如果是ext2/3用resize2fs没问题。另一种可能是重建分区表时分区类型代码写成了Windows或其它类型导致blkid读不到。这种情况用gdisk把分区类型改成Linux filesystem代码8300即可。4.4 xfs_growfs: XFS_IOC_FSGROWFSDATA: Invalid argument这个报错发生在执行xfs_growfs时系统告诉你无效参数。核心原因是分区容量在内核层面还没变大或者分区表更新根本没生效。排查顺序lsblk /dev/vdb1确认分区容量是否已经是800G。如果还是500G说明分区表没有真正更新回到partprobe那一步cat /proc/partitions看内核认识的分区大小。如果这里显示的是旧容量重启或重新扫描确认挂载状态xfs_growfs必须是挂载状态且挂载点参数要正确。还有一个小概率情况分区表更新了但文件系统检测到的块数没变化。这时检查是不是已经执行过一次xfs_growfs了xfs扩展后容量已经到位二次执行会报这个错实际是正常的。4.5 GPT PMBR size mismatch这个警告长这样Warning: The PMBR size is incorrect. GPT PMBR size mismatch (524288000 ! 838860800) will be corrected by write.PMBRProtective MBR位于GPT磁盘的第一个扇区它的作用是告诉老式BIOS/工具这是一块GPT盘不要乱动。云盘扩容后磁盘尾部增加了空间但PMBR里记录的大小还是旧值于是和新GPT头部记录的值对不上。处理方式很简单parted通常会提示你Fix/Ignore输入Fix即可。或者用gdisk更专业gdisk /dev/vdb # 先按 w 写入会问你是否重建PMBR选 Y这个警告不影响数据但建议修复否则后续有些工具会误判。4.6 扩容后df还是之前的容量分区表和文件系统都扩展完了df看到的容量却没变。先别怀疑眼睛按顺序排查df -hT /data看的是挂载点的文件系统容量不是分区容量。如果文件系统没执行resize2fs/xfs_growfs分区再大也没用。lsblk /dev/vdb1确认分区容量。如果分区容量没变说明分区表删除重建的步骤没生效。有时候resize2fs执行完了但输出提示No amend needed说明文件系统认为当前容量已经是最大了。这种情况通常是内核还没刷新分区视图执行完partprobe后再次resize2fs。检查当前shell是否在旧的挂载命名空间里如果用的是容器或者之前chroot过df的视图可能来自宿主机旧状态。开个新终端试试。4.7 No space left on device但明明有空间这个报错在扩容后也容易撞上但它跟扩容本身关系不大属于经典误区。手动df -h看还有几十G但写文件就是报No space left on device多半是inode耗尽了。df -i /data如果IUsed接近100%说明文件数量已经到了文件系统上限和数据块空间无关。解决办法是在文件系统层面释放无用文件或者重新规划目录结构。这个报错不在扩容的解决范围内但扩容时容易混淆所以一并列出来。5. 流程跑通之后我留下的几个习惯整套流程跑完说几个形成肌肉记忆的习惯希望能帮你少走弯路。分区操作前先抄作业。我说的抄作业是字面意义上的抄把parted /dev/vdb unit s print free的输出保存到本地最好再写进变更记录里。起始扇区、结束扇区、分区标志、文件系统类型这几项是最重要的以后不管遇到什么疑难杂症这些记录能帮你快速恢复现场。大版本变更永远备一份。冷备也好、快照也好、rsync也好不管操作多熟练磁盘上的数据永远比操作者有发言权。特别是数据库、日志分析平台这种对数据完整性要求极高的业务给云厂商打个快照只需要几分钟却能让你在操作失误时有一个体面的退路。能在线做的就别离线。扩展文件系统尽量在线操作减少业务停机窗口。ext4的resize2fs支持在线扩容xfs的xfs_growfs本身就是在线命令。真正需要离线的只有分区表删除重建那一步如果业务实在无法停可以尝试在挂载状态下删建分区表项但前提是内核能顺利重读且操作窗口很短。这种高风险操作我一般不建议新手尝试。分区表重建后第一个动作是e2fsck。这步相当于给文件系统做一次体检确保分区重建没有影响数据块映射。别的都可以省这一步我从来不跳。用UUID而不是设备名管理挂载。云环境里设备名漂移不是罕见事今天叫vdb明天可能就变成vdc。扩容完顺手把/etc/fstab里的路径换成UUID能避免很多重启后的挂载事故。这个习惯在所有Linux机器上都适用。最后再说一个容易被忽略的点整个流程都跑完、业务验证通过之后记得重新看一眼云监控里的磁盘使用率曲线。扩容后使用率会骤降但告警阈值如果设置过高或过低下次磁盘写满时你可能还是半夜被叫起来。结合自己业务的写入速度估算一下剩余可用天数必要时把磁盘扩容提前排进规划而不是等问题爆发再来处理。
