BLKRRPART ioctl

Russell Coker (russell@coker.com.au)
Sat, 31 Jul 1999 11:11:55 +0100


I have been looking into the issue of fdisk requiring a reboot. It seems that
if the device has a usage count >1 (the operation of fdisk counts as 1 for this
apparently) then it will not re-read the partition table.
I don't like this idea as I sometimes want to shuffle partitions around without
rebooting. Currently if I want to make /home smaller and the swap space larger
then I have to backup /home, run fdisk, reboot, then mkswap, mkfs, restore. I
would prefer to just backup, swapoff, umount, fdisk, mkfs, mkswap, restore
without a reboot.
As I am spending a fair bit of my spare time playing with RAID and ReiserFS my
need for reparitioning is great enough that I am considering building my
kernels with a patch to allow re-reading a partition table of a disk that is in
use.
Are there any potential problems in this? I imagine that if I had a mounted
file system and I deleted the partition then things could get nasty (but I
don't do that sort of thing anyway).
Also if the only issue is deleting or changing the size of a mounted file
system or swap space that is in use then I question the operation of this check
in a general sense. Maybe what we should have is two options in fdisk, one to
just save the partition table, and the other to save and tell the kernel to
re-read it. Or maybe for backward compatibility we should add a second ioctl
to re-read even if it's in use.
Maybe the correct solution would be to make the kernel check whether we're
changing any partitions that are in use - and only decline to re-read the table
in that case.

I consider it a minor bug that if for example I have my root file system on a
hard drive with 200megs of unpartitioned space then I will have to reboot to
create a new partition on that space.

--
This is the noise that keeps me awake

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/