[parted-devel] [PATCH 5/6] libparted: handle logical partitions starting immediately after the EBR

[Jim Meyering]

Phillip Susi wrote:

> On 12/15/2012 08:23 PM, Jim Meyering wrote:
>> Phillip Susi wrote:
>>> _blkpg_add_partition() set the length of the extended partition
>>> to 2 sectors to allow LILO to be installed there, beacuse the
>>> linux kernel does this.  If a logical partition used that second
>>> sector, adding it would fail beacuse of the overlap.  Now
>>> _blkpg_add_partition() will limit the length to only the first
>>> sector if the second is used by a logical partition.
>>
>> Hi Phillip,
>>
>> Thanks for your patience. I have a couple questions about this
>> change: - why?  The commit log (or perhaps comments in the code)
>> should tell us why this change is desirable.
>
> To allow for a partition to start on the first sector following the
> MBR, which is a perfectly legal configuration.

The 2-sector minimum is documented to apply to the distance between
the start of an extended partition and its first logical partition.
Can you rephrase why you want to make this change in that context?  I.e.,
we're perfectly capable of making the first *primary* partition start
right after the MBR, but if you're talking about a logical partition,
you cannot make it "start on the first sector following the MBR", even
with your change, since there's still a one-sector minimum separation.

>> - if we make this change, won't that let parted create partition
>> tables that cause older linux kernels to object?
>
> No, the kernel has never objected to such an on disk partition layout.
>  What it objects to is being told about it via BLKPG.  When it

Last I heard, the implementation of the BLKPG ioctl code was in
the kernel ;-)  The point is that if we make this change, then
we're exposing users to problems whenever they use that ioctl
against a partition we've created.  E.g., older versions of parted
do that.  Not that we have to be beholden to them, but please do at
least mention this possibility somewhere.

> encounters such an on disk layout, it happily accepts it and generates
> two overlapping partitions in memory.
>
>> - if you do change the code not to require the 2-sector "size",
>> please also change the name of that test script.
>>
>>> libparted/arch/linux.c                          |   10
>>> +++++++++- tests/t2310-dos-extended-2-sector-min-offset.sh |   20
>>> ++++----------------
>
> So you suggest renaming it to 23210-dos-extended-1-sector-offset.sh?

Sure, though s/23210-.../t3210-.../