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

[Jim Meyering]

Hans de Goede wrote:
> 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.

Whether extended partitions can exist is partition-table-specific, of course.
I assume you realize this and that any changes will work just as well
with, say, GPT partition tables.

>> 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.

I agree.  Go for it.

Please test thoroughly and at least outline your tests with
enough detail that I can easily convert them to regression test scripts.
Better still, write the tests (model after an existing one that uses
t-lib.sh, (the ones that use the older "test-lib.sh" are gradually
being rewritten).

Your tests will probably require root access; don't hesitate to model
new ones after the existing ones that do that.