[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reboot problem after altering the disk label
From: |
Andrew Clausen |
Subject: |
Re: reboot problem after altering the disk label |
Date: |
Sat, 26 May 2001 07:44:59 +1000 |
Matt Wilson wrote:
>
> fdisk does nothing different than parted when it comes to BLKRRPART.
> You can use parted to modify partition tables on a disk that has a use
> count 1 (one rw fd pointing to the disk, no mounted partitions, etc.)
> In this case the BLKRRPART will succeed and the ll_blk system will
> have the new geometries loaded.
>
> If the disk is being used, you still have to reboot.
Yep, right.
I should mention, 2.4 has a new blkpg interface, which
allows you to update the kernel's idea of the partition
table incrementally. So, if only / is mounted, you can
still tell it about the resized swap, or whatever.
(the interface allows you to add and remove partitions)
I've been meaning to implement this for ages...
One dilemma: I think this is more an "OS" issue than
a partition table issue. So, I think the code for blkpg
should be in the same place as the RRPART ioctl.
It would basically look like:
static void
set_kernel_part_entry (PedDevice* dev, PedPartition* part)
{
ioctl (dev->fd, BLKPG_REMOVE, part->num);
ioctl (dev->fd, BLKPG_ADD, {part->num, ...});
}
static void
update_part_table (PedDevice* dev)
{
disk = ped_disk_open(dev);
for (part ...) {
if (!ped_partition_is_active(part)) continue;
set_kernel_part_entry (part);
}
/* remove deleted partitions? why bother? Overlapping
* might cause issues? Anyway, trivial enough to do ;-)
* traverse the kernel partition table, and try
* ped_disk_get_partition(disk, N)...
*/
ped_disk_close();
}
See the recent thread on linux-fsdevel, BTW. An interesting
result of this would is it allows us to remove partition table
support from the kernel. Just have Parted parse it from an
initrd ;-)
I'm still not sure if that application is a good idea...
(initrd's don't excite me)
To implement the above code in 1.5.x, I think the
kernel_set_part_entry() should be kernel-specific, and
the update_part_table() should be public, and abstract.
(i.e. ped_device_update_kernel_table() ?)
Andrew Clausen