Messages in this thread | | | From | Russell Coker <> | Subject | BLKRRPART ioctl | Date | 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/
| |