[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 07:04 PM, Phillip Susi wrote:
> On 3/18/2010 12:17 PM, Hans de Goede wrote:
>> I don't remember the exact details, but iirc the blkpg code worked by
>> first removing all partitions, and re-adding them ignoring all
>> errors in the process to allow "skipping" busy partitions.
>
> It appears so.
>
>> Only making it remove / re-add changed partitions would have required
>> serious reworking of the code in question. So I opted for just throwing
>> it out all together.
>>
>> Also BLKPG does not work on all types of partitionable devices (it does
>> not work for example on dasd disks).
>>
>> Anyways, as said doing BLKPG correctly requires some significant
>> reworking of the old code, patches welcome.
>
> I'm taking a look at it now.  My first thought was to check for the
> removal failure, and as long as you are about to add the partition back
> exactly the same way, ignore it, otherwise, propagate the error up.
> Does that sound good?
>

Yes something like that should work, although I myself was thinking more
along the lines of adding a dirty field to the diskspecific partition
data struct, and using that, and not trying to remove unchanged partitions
at all.

Thinking more about this, consider this scenario (another example of
why I went the easy route and just cut out BLKPG support):

Disk has an extended partition, lets say sda4

The extended partition has 3 logicals in it:

sda5, sda6, sda7

sda5 and sda6 get removed, and replaced by a single new
logical.

Note that sda7 now has become sda6 in for example parted print
output.

Questions:

1) If a partition number changes, should it be marked as dirty
    (So removed and re-added using BLKPG), IMHO: Yes

2) What if sda7 is busy ? Options:
    a) leave it as sda7, inconsequent with parted print output,
       end result confused user, also see below wrt fstab
    b) Fail the commit
       User: but I'm allowed to change partitions as long as I
       don't touch the ones which are in use,
       end result confused user

Also note how in this scenario with 1.8, even if the user was
smart enough to not touch any in use partitions, things
would still not be the same as after a reboot (sda7 after commit
becomes sda6 after reboot). sda7 mentioned in fstab by device node
name -> fail

So given the above I would like to retract my "patches welcome"
statement and replace it by:
"Using BLKPG just is not a very good idea IMHO"

I know people were used to the old behavior, but the old
behavior relied on a lot of brokenness.

Regards,

Hans