Re: [**solved by a reboot**] moving (and losing?) partitions with cfdisk

["Daniel B." <REMOVEdanielTHIS@fgm.com>]

Levi Waldron wrote:

> 3.  after changing your partition table, you really do have to reboot
> - at least this is my best guess as to what the problem was.

Sometimes you can avoid the need to reboot:

If you can unmount every other partition that is on the disk whose
partition table you are modifying, then when you write the partition
table with fdisk or whatever, the kernel can re-load the partition
table and you won't get the message about needing to reboot for the
changed partitioning to take effect.

Of course, that doesn't work for the disk containing your root
filesystem partition (because you won't be able to unmount that
partition because it's in use), but it can save rebooting if you're
repartitioning a different disk.


But here's a question:  Why can't the kernel handle some types of
changes to a partition table (e.g., a new partition) while some
partitions are mounted?

It seems that the kernel could compare the current partition table
with the previous state of the partition table (using its in-memory
data structues derived from the partition table) and determine
whether any in-use partitions have changed.  If there have only been
deletions of partitions that are not mounted and/or additions of
partitions, then couldn't the kernel assimilate the changes (deleting
data structures for deleted partitions and creating data structures
for new partitions)?

So why doesn't the kernel do that?  Is it just that no one felt it
was a useful enough feature to implement?  Is it that the kernel's
data structures (or code using them) aren't set up for deleting and
adding partitions incrementally?  Or is there some bigger limitation?

Daniel