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

[Petr Uzel]

On Thu, Jan 15, 2009 at 01:52:31PM +0000, Bryn M. Reeves wrote:
> Petr Uzel wrote:
> > The problem is described in
> > https://bugzilla.redhat.com/show_bug.cgi?id=441244
> > with detailed instructions how to reproduce it and a patch.
> > 
> > I can confirm that the patch fixes the problem for me, but it
> > did not get it to parted. As Bryn wrote in comment #2, it needs some
> > discussion because of the possible interference with bootloaders (I'm
> > going to test what might happen with grub/lilo installed to extended
> > partition in this case).
> 
> Hi Petr,

Hi Bryn (and others),
thanks for the quick response.

> 
> It's a slightly awkward problem; what I'd like to see is that parted's 
> manipulation of the kernel partition tables leads to the exact same 
> result as the kernel's own partition table code, by whatever mechanism 
> parted uses.
I agree, this is of course desirable.
 
> Unfortunately, as you'll see in the comments in Red Hat bug 441244, 
> this is impossible with the BLKPG API (the kernel enforces stricter 
> constraints on userspace than on its own partition detection code: 
> specifically that partitions may never overlap. I don't necessarily 
> think that's a "Bad Thing" btw!).
> 
> 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 inclined to think that it may be better to fix the BLKRRPART 
> ioctl instead - if this allowed reloading a busy partition table iff 
> there are no conflicts between the old/new state then all this munging 
> via BLKPG would not be necessary. As it stands, if even one partition 
> is busy the kernel will not re-read the partition table (even if you 
> just added a new partition in previously unused space - an operation 
> that is clearly safe). At least, this was the state the last time I 
> tested - I'll get back and try this on a recent git to make sure.

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?

> 
> If anyone else has ideas on this I would really love to hear them.

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