How Linux Uses Partprobe for Partition Changes

The partprobe command in Linux is a critical utility used to synchronize disk partition modifications with the operating system's kernel. When partition tables are altered using tools like fdisk or parted, the changes are written directly to the storage drive, but the kernel's in-memory representation may remain outdated. partprobe bridges this gap by querying the disk's updated partition layout and instructing the kernel to refresh its internal block device structures immediately, eliminating the need to reboot the system to recognize new or modified storage boundaries.

The Disconnect Between Disk and Kernel

When a storage drive is partitioned, the changes are committed to the disk’s metadata sector, such as the Master Boot Record (MBR) or GUID Partition Table (GPT). However, the Linux kernel does not continuously monitor storage hardware for metadata edits. Instead, it reads the partition table during the boot process or initial device discovery and keeps an internal map of partitions in memory.

If a partition is added, resized, or deleted while the system is running, the kernel continues to reference its cached table. This results in the operating system being unable to find newly created device nodes (such as /dev/sdb2) or miscalculating the available space on resized partitions.

How Partprobe Works Under the Hood

partprobe, which is part of the GNU Parted package, resolves this synchronization issue through a series of direct kernel interactions:

  1. Reading On-Disk Metadata: When executed, partprobe reads the partition table directly from the specified block device (or all available block devices if no specific drive is specified).
  2. Issuing Kernel System Calls: Once the updated layout is read, partprobe issues an ioctl (input/output control) system call to the operating system. Historically, this has been the BLKRRPART (Block Request Re-Read Partition Table) request, though modern implementations may use the BLKPG ioctl to add, delete, or resize specific partitions directly without dropping the entire table.
  3. Kernel Memory Reconstruction: Upon receiving the ioctl request, the kernel flushes its old cached partition information for the device, reads the physical table afresh, and rebuilds its internal device maps.
  4. Updating the Virtual Filesystems: The kernel updates its virtual filesystems—primarily /sys/class/block/ and /proc/partitions—to reflect the new boundaries, sectors, and partition counts.
  5. Udev Event Triggering: The kernel notifies udevd (the device management daemon) of the changes. In response, udev dynamically creates, modifies, or removes the corresponding device nodes in the /dev directory.

Limitations and In-Use Partitions

While partprobe is powerful, the Linux kernel enforces safety checks to prevent data corruption. If any partition on the target disk is actively mounted, holds active swap space, or is part of an assembled LVM volume or software RAID array, the kernel will refuse to execute a full table re-read via BLKRRPART. In such cases, the system call fails with a Device or resource busy (EBUSY) error.

To overcome this, modern systems require unmounting the active partitions prior to running partprobe, or utilizing partition-specific tools like growpart or partx -u, which leverage the BLKPG interface to resize an individual in-use partition without disrupting surrounding partitions.