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

[Petr Uzel]

On Thu, Jan 15, 2009 at 03:18:00PM +0000, Bryn M. Reeves wrote:
> 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?).

This sounds reasonable. Thanks for the explanation.

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

So if BLKRRPART interface were fixed (let's suppose it is still broken
in the way you have described earlier), will parted switch to it? I'd
really like to invest some time to get this fixed, but need to know
which way to go :)

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

IMHO fixing one of those ioctl interfaces might be the first step.


Thanks,

-- 
Best regards / s pozdravem

Petr Uzel, Packages maintainer
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                          e-mail: puzel at suse.cz
Lihovarská 1060/12                          tel: +420 284 028 964
190 00 Prague 9                             fax: +420 284 028 951
Czech Republic                              http://www.suse.cz