Linux分区表重载全攻略：从内核缓存到partprobe/partx实战

改完分区表以后系统死活不认新分区这是Linux运维里特别常见的一个“小问题”。你的fdisk操作明明已经显示成功lsblk里却看不到新划分的区块网上搜一圈答案五花八门有让你重启的、有让你跑partprobe的、还有让你用partx的试了半天不知道该信哪个。其实这块知识不难难的是把内核的分区缓存机制、工具的实现原理、以及不同硬件场景下的特例串起来理解。这篇文章就围绕“Partition Table in Linux: Quick and Easy Way to Reload”这个主题把分区表重载的完整姿势、原理、踩坑和稳定脚本一次讲透。1. 为什么我不重启就不能“看见”新分区内核分区缓存机制1.1 分区表不是改了磁盘就立刻生效的很多人第一次踩这个坑时会觉得奇怪分区表是存在磁盘上的fdisk改完以后明明是写入成功了为什么lsblk还是旧样子问题出在“磁盘上的数据”和“内核内存里的数据”是两套东西。Linux内核在启动时或者磁盘设备被检测到时会把磁盘的MBR/GPT分区表读取一遍然后在内存里建立一份分区结构保存在block_device对应的gendisk结构里。之后所有应用层工具——lsblk、fdisk -l、blkid、mount——查询的都是内核内存里的这份缓存。fdisk、parted这一类的分区工具干的活是直接读写块设备上的扇区数据。它们修改的是磁盘上保存分区表的那几个扇区并不会主动通知内核去重新读取。于是在这个窗口期磁盘上的真实分区表已经变了内核却还抱着旧的那份不放。要想让系统识别到新分区就必须要走一遍“重载”流程让内核重新解析磁盘上的分区表信息。1.2 内核提供哪些“重载”通道Linux内核针对分区表重载实际上提供了不同粒度的几个系统调用关系。了解它们比背命令更重要。第一个是整盘重读。用户空间对块设备发起一个特定指令本质是BLKRRPART这个ioctl内核收到以后会把整个磁盘的所有分区全量清掉然后重新扫描分区表再逐个重新建立分区。这是颗粒度最大、最彻底的方式副作用也最大所有正在使用的分区包括挂载中的文件系统、正在写入的磁盘I/O都会在这个动作前后被“打断”。如果分区正忙内核会直接拒绝这个操作返回设备忙。第二个是单分区热插拔。内核提供了BLKPG_ADD_PARTITION和BLKPG_DEL_PARTITION操作可以只添加或删除某一个分区不动其他分区。这种路径比整盘重读温和得多只要正在操作的目标分区没有被使用内核就允许你动态加进去不影响磁盘上其他已经在工作的分区。第三个是磁盘驱动层的事件通知。比如SCSI设备执行RESCAN会触发驱动重新扫描整个设备。blockdev、hdparm工具的重载功能本质上是走了类似的内核路径。工具层面各有侧重后面会详细讲。但先把底层机制记清楚整盘重读最彻底但最挑环境单分区热插拔最轻量适用性最好驱动层重扫描适合特定总线设备。理解了这三条路径你在选工具的时候就不会只靠“试”。1.3 什么情况下必须要重载分区表不是所有分区操作都需要重载。你只是想查看分区表信息比如跑一下fdisk -l读磁盘头部这走的是设备原始读取不需要重载。真正需要重载的是以下这些场景。新增分区时分区表里多了一个新分区的条目但内核还没在内存里建立对应的分区块设备所以/dev/sdb1这类设备节点不存在后续的mkfs、mount全都会失败。删除分区时磁盘上分区的条目没有了但内核内存里还留着这个分区的block_device如果分区没卸载就直接删除可能导致系统仍然保留旧分区设备的访问能力。修改分区类型时比如把某个分区从Linux filesystem改成Linux LVM或者从Linux filesystem改成swap内核内存里记录的分区类型元数据需要同步刷新否则blkid和mount的判断逻辑会按旧类型走。调整分区大小后内核内存里的分区尺寸参数还是旧值直接使用会出现容量不更新甚至数据访问异常。任何一种场景本质都是要解决“磁盘存储区真实状态”和“内核内存缓存状态”不一致的问题。而重载分区表的本质就是让内核抛弃旧的缓存、按真实状态重新建立分区模型。2. 三大主流重载工具的实现原理和适用边界2.1 partprobeparted家族的标准动作partprobe是GNU parted项目里自带的一个重载工具很多发行版默认安装了parted就会带上它。它的工作原理非常简单打开磁盘块设备然后向内核发出整盘重读指令也就是前面提到的BLKRRPART路径。在这条路径下内核会尝试把整个磁盘的分区表重新解析一遍。从使用角度看partprobe的语法很简洁一条命令直接指定设备名就行partprobe /dev/sda执行成功通常没有任何输出执行后可以用partprobe -s查看内核当前实际识别的分区摘要或者直接lsblk确认。需要注意partprobe在“没有分区被占用”的前提下是最清爽的方案。一旦有分区处于挂载或者被某个进程独占状态内核判断设备忙partprobe就会回报失败。在部分老版本内核里还会出现一种更隐蔽的情况设备不忙但某些分区正在使用内核会静默跳过正在使用的分区只重读空闲分区看起来像是partprobe“没有生效”。2.2 partx利用内核热插拔能力的轻量方案partx是util-linux包里的工具和fdisk、lsblk是同一个父亲。它的工作原理和partprobe有本质区别partx默认不会整盘重读而是直接调用内核的单分区热插拔接口可以单独添加或删除某一个分区。这意味着一个非常实用的场景磁盘上的分区A正在被挂载使用你在同一块磁盘上新增加了分区B。这时候跑partprobe大概率会遇到“设备忙”但partx完全不受影响——因为不需要重读整个磁盘只需要热插拔新增分区B。典型用法# 将磁盘上分区表里存在的、但内核尚未识别的分区全部添加进来 partx -a /dev/sdb # 只添加第5个分区 partx -a --nr 5-5 /dev/sdb # 删除内核中某个分区设备 partx -d --nr 5 /dev/sdb还有一个经常被忽视的选项partx -u /dev/sdb它是util-linux里的“更新模式”会尝试让内核对分区表的变更进行同步实际效果是对比磁盘上的分区表和内核已有的分区然后自动执行添加和删除。这个选项在部分发行版上存在行为差异但如果你的版本支持它是自动化脚本里很好用的一个折中方案。2.3 blockdev和hdparm从块设备层直接触发blockdev是util-linux里的块设备管理工具它重载分区表的参数是--rereadpt全称是“reread partition table”实现路径同样是BLKRRPART整盘重读。和partprobe相比blockdev的可脚本化程度更高输出更干净也更容易嵌入到初始化流程里。blockdev --rereadpt /dev/sdahdparm则有专门的-z参数它的设计初衷是唤醒已经休眠或状态异常的磁盘并重新读取分区表。在SATA硬盘上它比较可靠但对SD/MMC、部分USB存储设备、虚拟化设备效果不稳定。今天的运维环境里直连物理SCSI/SATA设备的服务器仍然会遇到需要使用hdparm -z的场景比如某些老RAID卡驱动的刷新路径和通用工具配合不好时。用一个表格把这几个主流工具的关系梳理清楚选型的时候会更直观工具底层路径重载范围设备忙时表现典型适用场景partprobeBLKRRPART整盘全量直接报busy分区无占用的干净环境partx -a/-dBLKPG_ADD/DEL_PARTITION单分区不受影响有分区正在挂载只想加/删新分区blockdev --rereadptBLKRRPART整盘全量报设备忙脚本化自动操作hdparm -z驱动层重读整盘根据驱动不同物理SATA/SCSI设备特例2.4 还有几个“伪重载”工具要避坑网上很多帖子会推荐一些看起来也能刷新的命令实际效果有偏差需要分清。比如fdisk工具本身在部分交互流程里会尝试通知内核分区表变更但它是给“当前fdisk正在处理的那一次操作”服务的离开交互会话后内核状态未必更新。再比如kpartx这个名字很像partx但它实际上是用来处理DM-Multipath设备的设备映射器分区识别的不是标准分区重载工具主要用于映射出带分区格式的多路径设备节点。直接对着/proc/partitions这个文件来提醒自己内核识别的分区列表最终就是反映在/proc/partitions里。任何重载工具的成功最终都要用这个文件或者lsblk来验证。3. 按场景拆解不同磁盘类型下的重载操作清单3.1 MB/ GPT普通磁盘新增分区标准三步走最基础的操作场景拿fdisk在/dev/sdb上新建一个分区。假设新增的是第4个分区这里给一套完整、可复现的操作路径# 第一步创建分区 fdisk /dev/sdb # 进入交互模式依次选 n - 4 - 起始扇区 - 结束扇区 - w 写盘 # 第二步重载分区表 partprobe /dev/sdb # 如果报busy则改用partx只加载新分区 partx -a --nr 4-4 /dev/sdb # 第三步验证 cat /proc/partitions | grep sdb ls /dev/sdb4 blkid /dev/sdb4partprobe成功的情况下第三步里的/dev/sdb4设备节点就会出现。判断重载成功的标志不是某个命令输出了“success”而是/proc/partitions里确实出现了新分区的记录而这个分区对应的块设备节点存在。3.2 有分区处于挂载使用状态时partx才是主力这是服务器生产环境里最常遇到的尴尬情况。你在一台还在运行的机器上给某个磁盘新增了一个分区磁盘上还有一个正在持续写入的业务分区不能停。整盘重读的partprobe和blockdev在这个场景下几乎必失败因为内核不允许在分区被占用时清空重建整个磁盘的分区结构。这个时候partx的组合拳最为合适。比如磁盘/dev/sdc已经有1、2两个分区在挂载你新创建了分区3partx -a --nr 3-3 /dev/sdc只加分区3不影响1和2的热插拔状态。执行完以后直接对/dev/sdc3进行mkfs和mount业务分区的I/O完全不受影响。实测下来这是在线新增分区时最稳的方式。如果场景变成“需要在挂载状态下临时删除一个分区”注意顺序先卸载对应文件系统再执行partx -d --nr 3 /dev/sdc最后再用fdisk改写磁盘上的分区表反了的话设备忙问题会非常难缠。3.3 分区类型被修改后如何快速刷新识别有时你只是想改变分区用途比如把一个数据分区的分区类型从Linux filesystem改成Linux swap。分区在磁盘上还是同一个无论起始扇区还是大小都没变但内核内存里的分区元数据里记录的类型变了需要在应用层同步。如果该分区没有被挂载直接用partprobe重读整个磁盘没有占用刷新非常干净partprobe /dev/sdb partprobe -s /dev/sdb如果分区本身已被挂载partprobe会因为设备忙而失败。你又不希望卸载这个文件系统。这种情况下partx的单分区操作也不能直接更新“已存在分区的类型”因为内核的BLKPG_ADD是针对新分区对象的已存在且在使用的分区要修改元数据就不像新增那么轻量了。经验是分区类型修改这种操作最好放在文件系统卸载状态下进行而不是强撑着在线改。3.4 虚拟化磁盘的热扩容重载驱动决定一切云服务器、虚拟机里给系统磁盘扩容这块需要单独拿出来讲。虚拟化环境里的磁盘设备比如KVM的virtio-blk、Xen的xen-blkfront、VMware的pvscsi它们本身是宿主机动态发布的虚拟设备。你在guest机里用fdisk改了分区表以后guest内核并不会因为宿主机调整了磁盘容量就自动感知到容量变更。在做热扩容的时候有些环境需要先让驱动重新协商设备容量再重载分区表。常见的做法是先触发一次设备重新扫描echo 1 /sys/class/block/sda/device/rescan然后在设备容量更新以后再用partprobe或partx重载分区表。需要注意不同虚拟化平台对这个rescan的支持程度不一样。部分virtio设备在guest机里根本不支持在线rescan无论你跑什么重载工具内核始终只认识旧容量。这种情况就只有重启guest系统或者热插拔磁盘设备让内核重新检测到新设备。很多人以为这是重载工具没选对实际上卡点在驱动层。3.5 NVMe设备的重载差异NVMe协议和传统SCSI/SATA的磁盘检测方式不同NVMe有自己的namespace管理机制。在Linux里NVMe设备的namespace变化通常由nvme驱动自动处理但分区表的重载路径没有本质区别。实测在常见NVMe设备上新增分区后partx是比partprobe更好的选择。原因是NVMe控制器在多个namespace之间并发处理I/O时整盘重读的触发会影响同一控制器下其他namespace的I/O状态而单分区热插拔的干扰面更小。如果遇到NVMe磁盘partprobe卡住的情况先检查内核日志dmesg | tail -50看到类似“nvme nvme0: I/O 56 QID 0 timeout”这类信息就说明重载操作已经触发了设备I/O超时。出现这种情况后立刻停止重载操作等待控制器恢复必要时释放占用再试。4. 那些年我们踩过的分区表重载坑4.1 partprobe提示busy怎么排查到底是谁占的partprobe报“busy”的直接原因就是至少有一个分区正被系统使用。但“使用”这个概念比很多人想得要宽。文件系统挂载是最常见的一种某个进程持续用到了分区设备文件也算SWAP分区即使你没主动挂载任何东西只要还在交换空间状态它照样让设备处于忙状态LVM卷组里的物理卷成员设备、mdadm软RAID的成员设备、还有某些容器存储驱动占用的块设备都属于内核视角里的“正在使用”。排查道路按照从易到难来排列# 查看所有挂载点 mount | grep sda # 查看占用块设备的进程 fuser -v /dev/sda1 lsof | grep sda # 查看swap情况 swapon --show free -h # 查看设备是否被LVM、mdadm引用 pvs | grep /dev/sda cat /proc/mdstat | grep sda实战里最容易被忽略的是LVM场景。一块磁盘的某个分区被pvcreate加入了卷组表面上看它没有挂载点lsblk里也只是一个LVM member但partprobe对整块磁盘重读时一样会被拒绝。正确操作是先pvdisplay确认物理卷引用关系然后决定是否用partx避开整盘重读。4.2 partx把旧分区也重复加载了用partx直接不带参数跑partx -a /dev/sdb在部分分区表场景下会出现一种很尴尬的结果内核里旧的分区还在partx又把磁盘上同一个分区以新的分区号再次添加进去/proc/partitions里出现两个一模一样起始扇区结束扇区的分区条目但设备节点一个是/dev/sdb1另一个可能是/dev/sdb5之类的奇怪编号。原因在于partx默认不会去对比“内核已有分区”和“磁盘当前分区表”的差异它只负责机械地把磁盘分区表里存在的分区挨个往内核里塞。所以刚从fdisk里改完分区表、内核还没任何变化时直接partx -a没问题如果中间你手动用partx删过某个分区或者内核曾识别过一份旧表第二次不加范围地partx -a就可能重复。对策就是永远显式指定分区范围。新增分区时直接写partx -a --nr 5-5 /dev/sdb删除时对应partx -d --nr 5-5 /dev/sdb养成习惯以后重复添加的问题基本不会遇到。在自动化脚本里尤其重要否则一个idempotent逻辑可能因为你没指定范围而反复向内核插重复分区。4.3 “fdisk -l看到新表系统就是不认”的根因排查重载失败时先要分清“工具到底有没有成功”。很多人的误区是看fdisk的输出但fdisk读的是磁盘上的真实扇区重载工具改的是内核内存。你fdisk -l看到一个“新分区表”和“内核认不认”完全是两件事。真正要看的是内核视角。一条命令足够定位cat /proc/partitions如果/proc/partitions里根本没有新分区条目那不管fdisk -l显示得多漂亮内核就是没有重载成功。此时再回头看tools的报错、看dmesgdmesg | tail -20常见的内核日志会有两类提示一类是“device is busy”说明存在占用另一类是“invalid partition table”说明内核重读后解析分区表失败了。前者按前面4.1的方法逐步释放占用后者就要考虑是不是分区表本身有问题——比如GPT备份头损坏、分区首尾扇区重叠、或者磁盘尾部还有一层dm设备映射缓存。另有一个容易和“不认”混淆的情况是分区表重载成功但udev还没完成设备节点的创建工作。这时候/proc/partitions里有条目lsblk却看不到/dev/sdb4。跑一下udevadm settle让udev把所有排队的事件处理完节点就会生成。这个坑在脚本里尤其阴险因为你紧接着写的mkfs会直接报找不到设备。4.4 重载分区表把分区表“搞坏了”怎么办有一种极端情况必须提醒如果磁盘上的分区表本身有问题比如新版软件写入的GPT格式兼容性不好、或者分区表的备份头在主头损坏后被错误同步那执行整盘重读不仅不会恢复还可能让内核拒绝承认整个磁盘。遇到这种问题先不要继续跑任何重载工具立刻备份当前磁盘上分区表的原始扇区数据。常用工具是dd把磁盘头部的几百KB数据保存下来这比什么都保险dd if/dev/sdb of/tmp/sdb-first-1M.img bs1M count1然后用gdisk或testdisk检查分区表结构确认GPT主表、备份表、MBR引导代码区域是否一致。多数情况下修复手段是恢复备份GPT头再重载一次。如果备份头也损坏就需要用testdisk扫描重建分区表。这个环节非常考验细心程度每一个分区边界都必须在确认无误后才写盘。重载工具本身不会破坏分区表但会因为“重读了不健康的分区表”而暴露系统异常。保持一个好习惯任何磁盘的分区表结构性变更前先把分区信息和关键扇区数据备份下来。4.5 为什么“重启大法”有时候真的是唯一解讲再多工具有些场景下重启就是唯一正解。物理机器上加了一块新盘、导入了新的阵列配置、换了RAID卡的Cache策略这些在驱动层对设备拓扑的影响比分区表重载的范畴大得多。内核在启动过程中对磁盘设备的初始化参数很多在运行期是不允许动态修改的。虚拟化环境下如果碰到“宿主机已经扩容虚拟机内核始终容量不变”的情况如果你试过了rescan、partprobe、partx都没作用那就老老实实选维护窗口重启。这不是技术水平问题这是Linux设备模型本身的边界不是每个设备驱动都实现了完整的在线热插拔更新协议。从这个角度讲你可以把重启看成重载分区表的“终极大招”。前面讲的工具解决的是90%的常规场景剩下10%是驱动、固件、虚拟化平台能力的边界问题。先试着用工具解决解决不了别硬扛该重启就重启但重启前一定要确认分区表数据本身是完整的否则重启后系统可能直接无法挂载启动分区。5. 自动化脚本里的稳定姿势与验证细节5.1 一套尽量不打扰业务的重载函数把实践经验沉淀下来整理成一个稳定的shell函数可以在日常运维脚本里直接复用。设计目标是优先尝试整盘重读设备忙时自动回退到单分区添加整个过程不擅自卸载任何文件系统。reload_partition() { local disk$1 local part$2 if [ ! -b $disk ]; then echo error: $disk is not a block device return 2 fi # 第一步整盘重读 if blockdev --rereadpt $disk 2/dev/null; then udevadm settle return 0 fi # 第二步设备忙回退到单分区热插拔 if partx -a --nr ${part}-${part} $disk 2/dev/null; then udevadm settle return 0 fi # 第三步部分内核老版本需要直接处理特定分区设备 if [ -b ${disk}${part} ]; then return 0 fi return 1 }这个函数的使用约束是调用前必须确认分区表更新已经成功写入磁盘。函数内部不会替你去跑fdisk因为自动化脚本里的分区表创建逻辑和重载逻辑应该分离否则一旦fdisk分区指令没有按预期写入重载函数照样会报成功这就掩盖了真实故障。5.2 在初始化脚本中嵌入分区重载的正确时序在云服务器初始化脚本、或在裸机批量装机流程里分区重载的时序错误比工具选型错误更常见。典型的反例是脚本刚写完分区表立刻mkfs。中间缺少“等待内核完成重载等待udev创建设备节点确认设备可用”这串步骤。慢的机器上设备节点晚几百毫秒出来mkfs就直接失败了。推荐的完整时序如下用parted、fdisk或sgdisk写入新分区表同步等待命令正常退出。执行分区重载优先partx -a显式指定新分区号因为它不挑设备占用状态。执行udevadm settle或者等待固定时间轮询设备节点两种做法里轮询更可靠。检查/proc/partitions中是否存在新分区记录。再次确认设备节点可访问然后再跑mkfs。轮询逻辑写起来不复杂for _ in $(seq 1 20); do [ -b /dev/sdb4 ] break sleep 0.5 done [ -b /dev/sdb4 ] || exit 1这个轮询好过固定sleep因为不同场景下设备的响应速度差异很大。固定sleep短了不稳定长了拖慢脚本轮询在效率和稳定性之间均衡得最好。5.3 如何用/proc/partitions做终极验证很多人做完重载只会看lsblk但lsblk在部分情况下会联到udev数据库udev数据未刷新时lsblk的显示就可能有延迟。真正内核视角的验证通道是/proc/partitions它直接反映内核当前注册的分区设备。验证逻辑分三层第一层对比分区总数。重载前的/proc/partitions里少了新分区重载后多出来了这就是最直接的判定。第二层对比设备节点。对新增分区来说ls -l /dev/sdb4能查到设备文件说明udev也完成了配合。第三层确认容量。用blockdev --getsize64 /dev/sdb4读取设备实际字节数和分区表理论容量比对。这三层逐级确认后再进入mkfs阶段基本不会出现“重载了个寂寞”的问题。实战中我还会把重载前后的/proc/partitions输出存成变量做diff方便排障时清楚看到内核到底往哪个方向变化了。5.4 结合growpart自动扩容分区时的重载策略云环境里对根分区或数据盘做在线扩容经常配合growpart这种专门调整分区容量的工具。需要注意growpart会同时修改分区表信息并尝试通知内核。实际操作里它的重载结果并不可靠——部分版本growpart在结尾使用partx -u但环境不支持时静默忽略。所以使用growpart之后不要直接跑resize2fs或xfs_growfs需要先验证分区容量真的更新了。growpart /dev/sda 1 partx -u /dev/sda blockdev --getsize64 /dev/sda1blockdev读出来的字节数比之前大说明分区表重载生效然后再对文件系统做在线扩容。顺序反了的话文件系统扩容工具会认为分区没有变大直接拒绝执行或者只扩展了一部分。写在后面的一点经验分区表重载这件事工具只是表象真正可靠的心态是先理解内核的缓存模型。整盘重读是最经典的默认路径但生产环境里它最容易撞上设备占用partx代表的热插拔路径是最适合在线环境的活用分区号范围参数以后很少踩坑blockdev则是脚本场景里最干净利落的选择。把这些工具的底层路径记清楚再看各种“为什么没生效”的报错基本都能快速找到根因。我自己维护的机器上这套判断思路已经帮我解决了不少半夜告警如果你也在为分区表不生效的问题头疼希望这些经验能让你少走几趟弯路。