Linux – Difference Between BLKRRPART and BLKPG Ioctl for Partition Table

hdparmlinuxpartitionsfdisk

When I want Linux to consider newly created partitions without rebooting, I have several tools available to force a refresh of the kernel "partition cache":

partx -va /dev/sdX
kpartx -va /dev/sdX
hdparm -z /dev/sdX
sfdisk -R /dev/sdX
partprobe /dev/sdX
…

I'm not sure about the difference between these techniques, but I think they don't use the same ioctl, like BLKRRPART or BLKPG. So, what is the difference between those ioctl?

Best Answer

BLKRRPART tells the kernel to reread the partition table. man 4 sd

With BLKPG you can create, add, delete partitions as you please (from the kernel, not on disk of course). You have to tell the kernel the offset and size of individual partition, which implies that you must have parsed the partition table yourself beforehand. See Linux kernel: /include/uapi/linux/blkpg.h

I personally use partprobe (part of parted), which uses the latter approach, probably to support partition tables not supported by the kernel.

Related Solutions

How does partprobe work

Partprobe calls the BLKRRPART ioctl, which is documented in, err, include/linux/fs.h, and beyond that the kernel source (the meat is in rescan_partitions()):

#define BLKRRPART  _IO(0x12,95) /* re-read partition table */

The easiest way to find this out is to run strace -e raw=ioctl -e open,ioctl partprobe /dev/sdb.

I think what you tried with /sys/*/*scan tells the kernel to check if there's been a change of drive. That doesn't help if the drive hasn't changed (or has been hotswapped in a way that the kernel doesn't detect?) but the partition structure on it has changed.

ioctl Difference – Difference Between ioctl(), unlocked_ioctl(), and compat_ioctl()

Meta-answer: All the raw stuff happening to the Linux kernel goes through lkml (the Linux kernel mailing list). For explicative summaries, read or search lwn (Linux weekly news).

Answer: From The new way of ioctl() by Jonathan Corbet:

ioctl() is one of the remaining parts of the kernel which runs under the Big Kernel Lock (BKL). In the past, the usage of the BKL has made it possible for long-running ioctl() methods to create long latencies for unrelated processes.

Follows an explanation of the patch that introduced unlocked_ioctl and compat_ioctl into 2.6.11. The removal of the ioctl field happened a lot later, in 2.6.36.

Explanation: When ioctl was executed, it took the Big Kernel Lock (BKL), so nothing else could execute at the same time. This is very bad on a multiprocessor machine, so there was a big effort to get rid of the BKL. First, unlocked_ioctl was introduced. It lets each driver writer choose what lock to use instead. This can be difficult, so there was a period of transition during which old drivers still worked (using ioctl) but new drivers could use the improved interface (unlocked_ioctl). Eventually all drivers were converted and ioctl could be removed.

compat_ioctl is actually unrelated, even though it was added at the same time. Its purpose is to allow 32-bit userland programs to make ioctl calls on a 64-bit kernel. The meaning of the last argument to ioctl depends on the driver, so there is no way to do a driver-independent conversion.

Best Answer

Related Solutions

How does partprobe work

ioctl Difference – Difference Between ioctl(), unlocked_ioctl(), and compat_ioctl()

Related Question