[parted-devel] [BUG] failing ioctl when informing the kernel about new partitions

[Bryn M. Reeves]

Petr Uzel wrote:
>> Right now, I don't have a really good answer for this. The fix that 
>> was applied in RHEL allows this case to work but may mean that, after 
>> reloading the partition table in this way, bootloaders cannot access 
>> the EBR until after the next reboot. I have never had a report of this 
>> causing problems but it is a side effect of the (desired) reload fix.
> 
> Hmm, the more I'm thinking about this, the less I understand what
> actually might go wrong. If I understand it right, then the first 512B
> of extended partition will be accessible (as /dev/sda5 or so) even
> with the patch applied. I don't understand for what we might need to
> access the second 512B of extended partition - as the kernel and
> parted tries to achieve.
> 
> But may be I got it completely wrong...

I am not 100% clear on this myself (and there are not that many tools 
around today that want to manipulate EBRs anyway..), but this is what 
I understood from discussions around the time that patch was created.

Iirc, the 1st sector is the chained partition descriptor for the 
content of the extended partition & the 2nd is the EBR itself (might 
have those the wrong way around?).

> But isn't BKLPG interface superior to BLKRRPART in the fact that the
> kernel doesn't need to have support for particular type of disk label
> compiled in? If this is true, then it might be worth trying to extend
> BLKPG interface to support this kind of overlapping partitions instead
> of reverting back to BLKRRPART. What do you think?

Depends on your goals really :)

BLKRRPART more closely mimics the behaviour the kernel would adopt 
when detecting the device itself (since it uses the same in-kernel 
partitioning code), but BLKPG allows more control from a userspace 
application wishing to directly manipulate partitions. The problem is 
that it's not possible to implement the one in terms of the other 
right now.

I've had a few discussions along the lines of "wouldn't it be nice to 
rip all the partitioning code out of the kernel and do it all in 
userspace", and while I think there's actually some merit to that 
approach we're a long way off being ready to do that today.

Regards,
Bryn.