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

[Phillip Susi]

On 3/18/2010 3:50 PM, Hans de Goede wrote:
> 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

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.

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

It seems that BLKPG is the intended interface to use these days and
BLKRRPART is depreciated.  The idea seems to be to eventually remove the
partition detection code from the kernel completely and have it done in
user land.