新接的磁盘 lsblk 里能看到整块 /dev/sdb可 /dev/sdb1 怎么都不出现改完分区表系统蹦出 Re-reading the partition table failed: Device or resource busy云盘扩容后加大了的容量怎么都刷不回来看不见。这些场景丢到生产环境里很多人的第一反应是 reboot但重启一个正在跑业务、扛着数据库或容器集群的节点往往比磁盘操作本身更危险。Linux 其实早就提供了不重启重新读取分区表的完整方案只是不同工具底层机制不一样用错场景就很容易以为“只能重启”。这篇文章把我这些年摸出来的方案从底层原理到操作命令完整整理一遍覆盖 partprobe、partx、设备级 rescan、LVM 缓存刷新四条路径适合运维、SRE 以及所有需要在生产环境里动态调整磁盘布局的人。1. 先分清这两个状态磁盘介质上的分区表 vs 内核内存里的分区表1.1 内核默认不会每次操作都去读磁盘很多人以为改完分区表系统立刻就能感知到这其实是把“磁盘介质上的分区表”和“内核里的分区状态”混为一谈了。用 fdisk 或 gdisk 修改 /dev/sdb 的 MBR/GPT改的是磁盘扇区里的数据而系统在 lsblk、/proc/partitions 里展示给用户的 /dev/sdb1、/dev/sdb2 这些节点是由内核在启动时或上次重读时读取分区表后在内存中创建出来的块设备对象。也就是说内核相当于维护了一份“分区缓存在内存里的副本”如果没有专门的通知机制它不会主动去磁盘上重新读分区表。这个通知机制在 Linux 里就是两个 ioctl 调用BLKRRPART 和 BLKPG。BLKRRPART 的意思是“整盘重读”内核会锁住整个磁盘把所有分区设备重新建一遍它的要求很苛刻——整个磁盘上所有分区都不能处于打开状态否则直接返回 EBUSY。BLKPG 则是“单个分区操作”可以对 /dev/sda1、/dev/sda3 这样的具体分区做增量添加或删除不用整盘空闲。理解了这两个 ioctl后面所有命令的行为就都能解释了。1.2 哪些场景真正需要重新读取分区表我整理了日常最常遇到的三种情况对应的处理路径完全不同很多人搞不清到底该用哪个命令就是因为没区分这些场景。场景操作类型表象核心原因A新盘刚做完分区整块盘看得到分区节点不出现创建分区后内核没收到重读通知B已有磁盘增删改分区旧分区信息仍然生效/新分区看不到分区表已改内核仍用内存里旧副本C云盘/虚拟机磁盘扩容磁盘容量和分区大小都是旧值设备层容量未 rescan分区表重读没意义场景 A 和 B 用 partprobe 或 partx 就能解决场景 C 必须先做设备级重新扫描让内核知道磁盘本身变大了再回头重读分区表。顺序反了命令大概率都会失败或者看起来成功了但容量不对。这也是很多人在云环境里扩容失败的原因——不是 partprobe 没执行而是根本跳过了底层 rescan。从原理上说“重读分区表”从来不是单一命令而是一条链路设备层容量更新、分区表重读、分区设备节点同步、依赖分区的上层LVM、文件系统刷新。下面逐步展开。2. partprobe日常高频场景的主力命令2.1 partprobe 的底层逻辑与适用边界partprobe 是 parted 工具集自带的命令绝大多数发行版都已经预装这也是我日常用得最多的工具。它的行为分成两层先尝试对整个磁盘执行 BLKRRPART如果因为某个分区被占用而失败会自动退回 BLKPG 方式逐个分区同步。所以实际使用中你会发现一个挂着 /data 分区、正在被大量进程写入的磁盘用 partprobe 去重读它的新增分区经常是能成功的因为内核只需添加一个新分区设备不需要动旧分区。基本用法非常简单partprobe /dev/sdb不带设备名时会对所有磁盘做重读虽然方便但在生产环境里我不推荐容易误触到不想动的那块盘建议永远显式指定设备。如果你用的是 KVM 虚拟化实例设备名通常是 vda/vdb也一样传设备路径即可。2.2 实操在正在运行的机器上新增一个分区假设你刚在 /dev/sdb 上划了一个 20G 新分区想立即让它生效。传统写法往往是这样fdisk /dev/sdb EOF n p 1 20G w EOFfdisk 写入分区表后通常会打印一句类似 “The kernel still uses the old table. The new table will be used at the next reboot.” 这是我前面说的fdisk 自己调用 BLKRRPART 失败了。很多新手看到这句就以为必须重启实际上这时只要补两步partprobe /dev/sdb udevadm settle lsblk /dev/sdbudevadm settle 是我强烈建议加的一步。分区设备节点是 udev 异步生成的partprobe 返回成功只代表内核消息已经发出不代表 /dev/sdb1 这个设备文件已经在磁盘上立起来了。如果你在脚本里紧接着去 mount /dev/sdb1很容易撞上 “No such file or directory”。加一条 settle等待 udev 队列处理完再执行后续操作能省掉大量偶发问题。lsblk 验证时重点看两列SIZE 和 TYPE。确认 sdb1 出现了TYPE 是 part再用 mkfs、mount 做后续操作这才算真正完成。2.3 fdisk 那句“Device or resource busy”不是判决书“Re-reading the partition table failed: Device or resource busy”是我被问过最多的一句报错。很多人把它解读成“系统要求重启”其实这句只是说 fdisk 内置的整盘重读 ioctl 没有获得许可原因很简单当前磁盘上有分区正在被使用。你只需要确认新改的分区是否涉及正在挂载的分区本身如果只是新增分区、或修改一个未被占用的分区直接 partprobe /dev/sdb 基本都能成功如果修改的恰好是正在挂载使用的分区比如 / 或 /data那确实需要先 umount或者接受这个变更要等下次重新挂载。提示partprobe 也不是百分百成功。碰到它都失败的情况不要反复重试先执行 fuser -vm /dev/sdb、lsof /dev/sdb* 看看是谁占着盘再决定下一步。硬试只会让日志里堆满 EBUSY 记录没有任何实际帮助。3. partx当 partprobe 失灵时的精细操作3.1 partx 是 util-linux 里更底层的工具partprobe 绝大多数场景下够用但在我管理的机器上还遇到过两次例外。一次是内核里已经存在的 sdb1 设备项和磁盘上新的分区不匹配partprobe 因表项比对不一致而放弃更新另一次是 LVM 缓存引用了旧分区项BLKRRPART 始终拿不到整盘空闲。这种时候我习惯直接换 partx。partx 同样是 util-linux 自带的命令但它走的是更明确的 BLKPG 路径-a 是添加Add-d 是删除Delete-u 是更新Update。它不像 partprobe 那样先试整盘重读而是直接针对单个分区项做增量同步因此在很多 partprobe “罢工”的现场反而更有效。3.2 最常用的“先删后加”组合生产环境里我实际用得最多的是这个组合partx -d /dev/sdb partx -a /dev/sdb第一条命令删除内核中该设备下的全部动态分区项第二条命令重新从磁盘介质读取分区表、创建分区设备。删除操作只影响内核内存里的设备对象不会碰磁盘数据所以只要磁盘上的分区没有被挂载使用这个组合就是安全的。如果你的机器上该盘有空闲分区也有挂载分区不想影响挂载中的那部分可以精确到分区号partx -d --nr 3 /dev/sdb partx -a /dev/sdb处理完用 cat /proc/partitions 确认分区号已经刷新。实际经验里这个先删后加的动作比单纯 partx -u 要稳因为 -u 在某些老内核版本上只比对分区表项参数不一致才更新而先删后加是强制重建能覆盖更多异常情况。3.3 顺手把 kpartx 和 partx 的区别说清楚很多人在查分区表重读资料时会看到 kpartx网上还容易和 partx 混在一起。kpartx 并不做“重读分区表”这件事它是读取分区表之后为分区创建 device mapper 映射主要用于多路径、LVM 或者 loop 设备场景。如果你只是想让内核识别磁盘上的 MBR/GPT 分区用 partx 就对了开了 kpartx 反而可能多一层多余映射。这两个命令名字只差一个字母但职责完全不同别搞混。4. 底层设备没变内核就不会重新识别先做设备级扫描4.1 云盘/虚拟机磁盘扩容后的第一步不是 partprobe我在前面提过场景 C云主机或虚拟机在管理面板里把数据盘从 100G 扩到 200G登录进去之后执行 partprobe结果发现什么反应都没有。原因很直接——内核看到的磁盘容量还是 100G你让它在 100G 的盘上读分区表自然读不出新增的空间。SCSI 设备包括 KVM 虚拟化里的 virtio-blk 设备通常也会暴露为 SCSI 类接口需要先做一次设备级重新扫描echo 1 /sys/block/vdb/device/rescan # 如果是 sda路径就是 /sys/block/sda/device/rescan执行完 cat /sys/block/vdb/size 看看扇区数是否已经变大。内核把设备容量更新过来之后再执行 partprobe 或 partx分区才能识别到新尺寸。很多扩容教程只写了 growpart 和 resize2fs漏了最开头的 device rescan照着做的读者卡在第一步是必然的。4.2 全新热插拔磁盘的无重启识别另一个高频场景是虚拟化平台或物理服务器上热插拔了一块新盘但系统里找不到 /dev/sdc。这种新设备扫描用的命令是echo - - - /sys/class/scsi_host/host0/scan三个 - 分别表示 HBA 编号、通道、目标 ID是个通配符会扫描该 host 下所有可能的新设备。生产机器上通常有多个 scsi_host稳妥写法是遍历一遍for host in /sys/class/scsi_host/host*; do echo - - - $host/scan done执行完再 lsblk新盘一般就出现了。如果还不行再检查 HBA 驱动是否需要额外触发比如某些 SAS HBA 要求做 hotplug 配置但在绝大多数 Linux 发行版上这个遍历已经足够。NVMe 盘的路径不一样。NVMe 没有 scsi_host可以用echo 1 /sys/class/nvme/nvme0/rescan_controller # 或安装 nvme-cli 后 nvme rescan /dev/nvme0不同内核版本的 sysfs 支持略有差别rescan_controller 在较新内核里更通用。4.3 多路径存储和 LVM 的后续刷新如果你的磁盘走的是 dm-multipath比如常见的 FC、iSCSI 双活存储物理盘容量和分区变化后光做 rescan 还不够multipath 设备需要重新加载才能让上层看到新的路径和大小multipath -r multipath -l这一步经常被忽略。多路径环境下/dev/sda、/dev/sdb 只是物理路径设备真正暴露给文件系统的是 /dev/dm-X 或 /dev/mapper/xxx。分区表重读也必须落在 multipath 设备名上而不是物理盘路径上否则可能会读到不一致的内容。如果是 LVM 管的磁盘分区识别后还要刷新 LVM 缓存pvscan --cache vgscanLVM 自己也有设备缓存old PV 信息不清理的话即使分区设备正常lvdisplay 里看到的还是旧容量。刷新顺序应该是rescan → partprobe/partx → pvscan/vgscan → 后续 lvextend / 文件系统扩容。5. 设备忙导致重读失败完整排错链路回顾5.1 报错现场数据库服务器的系统盘改了分区partprobe 却失败说一个我实际排查过的案例。一台 RHEL 7 的数据库主机需要在系统盘 sda 上新增一个分区用于归档日志。fdisk 写表时提示 “Re-reading the partition table failed: Device or resource busy”我心里有数接着跑 partprobe /dev/sda没想到也报错。当时第一反应不是重启而是按下面顺序排查。lsblk /dev/sda # 看看有没有挂载分区谁在占用 fuser -vm /dev/sda1 # 具体到分区列出占用进程 lsof /dev/sda* # 列出所有打开的设备文件 pvscan --cache # 刷新 LVM 缓存排除缓存锁 partx -d /dev/sda # 尝试删除内核中旧分区项 partx -a /dev/sda # 重新添加真正的根因出在 LVM 上。/dev/sda1 和 /dev/sda2 都是物理卷PV虽然数据盘没有显式挂载但 LVM 的 device cache 始终握着这两个分区设备的引用导致整盘 BLKRRPART 一直拿不到“全盘空闲”的状态。partprobe 的 BLKRRPART 先失败它的 BLKPG 退回逻辑又因为 LVM 的引用没有及时释放而失败。处理方法是先把相关卷组临时停用让 LVM 释放设备引用vgchange -an 卷组名 partprobe /dev/sda # 确认分区表同步成功后 vgchange -ay 卷组名 pvscan --cachevgchange -an 会 deactivate 卷组里所有逻辑卷LVM 对底层分区的引用随之释放之后 partprobe 一下子就成功了。全部完成后 vgchange -ay 再激活pvscan --cache 把新分区信息同步到 LVM 缓存。整个过程不影响数据库服务器上其他未使用该卷组的应用比重启省事太多。5.2 排查思路永远先回答“谁占着分区”上面这个案例把排错顺序体现得很完整。遇到“重新读取分区表失败”我建议大家养成一个固定的排查顺序不要上来就反复重试 partprobe。第一步先回答“谁占着这个分区”lsblk 看挂载关系、fuser/lsof 看进程占用、lvs/pvs 看 LVM 引用。第二步再考虑是“整个磁盘都被占用”还是“只有个别分区被占用”——如果是后者尽量用 partx 只对目标分区做 BLKPG 增删避免和整盘 BLKRRPART 冲突。第三步才到命令选择整盘空闲用 BLKRRPARTpartprobe/blockdev --rereadpt 都可部分占用用 BLKPGpartx。另外提醒一句fdisk 写入分区表后它自带的整盘重读失败并不代表你的分区变更没有写入磁盘。写入动作和重读动作是两回事分区表已经改好了只是内核还没刷新所以不要为了“让 fdisk 不报错”去反复删除重建分区那只会破坏数据。5.3 什么情况下重启确实是唯一选项把话说公道一点我心里也有一个“确实必须重启”的名单删除了正在挂载使用的文件系统所在分区且这个文件系统无法卸载比如根分区被删这种情况已经不是重启能解决的了。改变了一个正在挂载分区的起始扇区或分区类型标识这类变更会破坏内核对该分区设备的既有认知。swap 分区正在使用而你需要缩小或删除它其实现场一般用 swapoff 就能处理但如果 swapoff 因为内存压力失败就得重启。场景能否不重启处理处理方式新盘分区后识别新分区可以partprobe / 或 partx -a扩容云盘/虚拟机磁盘可以device rescan partprobe growpart resize2fs修改未挂载分区可以partprobe 或 partx 先删后加修改已挂载分区的起始扇区不建议先 umount操作完再挂载删除正在使用的 swap特殊swapoff 后操作或重启6. 我的工作流备份、变更、重读、验证一个都不能少6.1 动手前先备份分区表重读分区表这个动作本身不危险危险的是前面的分区变更。生产磁盘上一个数字输错MBR/GPT 就可能废掉。所以我每次动分区表之前都会留双份备份sfdisk -d /dev/sdb /root/backup/sdb_sfdisk_$(date %F).txt sgdisk --backup/root/backup/sdb_gpt_$(date %F).bin /dev/sdbsfdisk -d 导出一个人类可读的文本定义恢复时可以直接sfdisk /dev/sdb 文件导回新版 util-linux 如果有提示加 --force 即可sgdisk --backup 导出一份 GPT 二进制备份恢复用sgdisk --load-backup文件 /dev/sdb。这两份文件都留着恢复失败了可以互相校验。备份文件建议放到别的机器或对象存储上防止磁盘本身损坏导致备份和原表一起消失。6.2 变更后的标准验证清单命令跑完不验证等于白干。我验证分区表重读是否成功固定看三样东西lsblk 的分区列表和 SIZE 是否满足预期。cat /proc/partitions 里是否出现对应的主次设备号。文件系统层的实际表现df -h、mount 结果。一个数据盘扩容的完整流程我通常这样串echo 1 /sys/block/sdb/device/rescan growpart /dev/sdb 1 partprobe /dev/sdb udevadm settle resize2fs /dev/sdb1 # ext4 文件系统 # 如果是 xfs挂载后执行 xfs_growfs /mnt/dataresize2fs 和 xfs_growfs 是两套完全不同的命令很多人在这一步踩坑ext 系列用 resize2fsxfs 用 xfs_growfs交叉使用直接报错。还有一个细节xfs 的 xfs_growfs 一般要求文件系统处于挂载状态和 ext4 离线扩展的习惯不一样如果拿 resize2fs 的思路去做 xfs多半会卡住。6.3 脚本化时的几个防呆点把重读分区表写进自动化脚本有几个坑我替大家踩过了partprobe 后面必须跟 udevadm settle否则 udev 异步创建设备节点会导致下一步操作瞬间找不到设备文件。判断分区是否生成不要用 lsblk 阻塞等待用ls /sys/block/sdb/sdb*或者 cat /proc/partitions 更稳。sysfs 里的目录生成早于 udev 设备的最终落盘脚本里用轮询 sysfs 的方式判断比依赖 lsblk 输出稳定得多。幂等性同一个分区变更任务不要每次执行都触发一次重读。用配置管理工具的话可以先判断 “/sys/block/sdb/sdb1 是否存在且 SIZE 符合预期”满足就不重读。大分区挂载前务必检查 /etc/fstab 里的 UUID 是否还匹配。分区表变更一般不会改文件系统 UUID但盘符漂移或分区编号变化可能导致 /etc/fstab 里的设备路径失效mount 之前用 blkid 重新确认一次最安全。6.4 最后分享一个小技巧这套内容如果只能记住一点我建议是记住 partx -d partx -a 这个组合。它在绝大多数“分区表已经改好、内核死活不认”的场景里都能兜底而且比 partprobe 更可控。我自己维护的机器里遇到新挂载盘选择最优方案临时盘用 partprobe 一条命令收工生产盘用备份 partx 先删后加 验证清单走完整流程。长时间实践下来几乎没有为磁盘分区重读重启过一台生产服务器这个概念上的“省事”很多时候就是线上服务可用性的关键差别。