[parted-devel] Bug: Removal of BLKPG causes regression of ability to manipulate disks with other partitions in use

[Phillip Susi]

On 3/18/2010 5:05 PM, Hans de Goede wrote:
> On 03/18/2010 09:49 PM, Phillip Susi wrote:
>> I think the only option is to require that the removal of an extended
>> partition that would cause such a renumbering should fail.  The user
>> will not be confused because they will get the same message they do now
>> when BLKRRPART fails, telling them that the kernel is still using the
>> old table and they need to reboot for the changes to take effect.  The
>> only difference from using BLKRRPART would be that the partitions NOT in
>> use with numbers higher than the one that was in use will have already
>> been removed from the kernel.
>>
> 
> True, that would work. Note that you will need to get Jim Meyering
> to buy on on this approach as well for it to get accepted upstream.

What if we iterate over the partitions starting from the last, opening
each device with O_EXCL, to test if it is in use.  If it succeeds, we
know that we can then remove the partition.  If we find an extended
partition ( number > 4 ) that we can't lock, then we note our current
position.

Then we restart iterating backwards down the list of extended
partitions, this time comparing the new partition table with the
kernel's current view of that partition.  If it differs, we know that we
need to delete that partition from the kernel table.  As long as this
partition is > the partition we stopped on above, we are fine, but if
not, we fail.

Now we know that it is safe to repartition, so we can iterate over the
partitions, comparing them with the current kernel view, and when they
differ, delete the kernel partition and add it back using the new settings.

This way we only delete partitions that actually change, and we do
nothing if doing so would result in renumbering extended partitions that
can not be deleted.