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. _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
