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

[Hans de Goede]

Hi,

On 03/18/2010 10:29 PM, Phillip Susi wrote:
> 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.

This sounds a bit complicated, but I think the intend of not making
any changes at all when we expect some changes to fail is very good,
so if you want to do give implementing this a try, go for it.

Regards,

Hans