Re: Possible enumeration approach

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I kept on testing this throughout the most part of the morning and I
feel that we should not use this patch.  There are two main reasons:

1. The patch is not valid for all types of partitions.  Its valid for
   primary, but not for logical.  The logical ones continue to be
   renumbered (even with this patch).

2. Even if we manage to figure out a way to make it work with logical
   partitions, it would not survive a reboot.

Some questions that need answering:
1. Why does it work with primary?
   With primary partitions there is a section of 4 consecutive partition
   structures (primary_part_structure).  When we use the patch, we avoid
   making sure that the partition structures are used consecutively.  In
   other words we can have something in primary_part_structure[0] that
   will always be called part1.  We can also have nothing in
   primary_part_structure[1] and it would be a slot only for part2. And
   we can have something in primary_part_structure[2] that will always
   be called part3.
   Without the patch the slots without partitions are pushed to the end
   and the ones with something on them are pushed to the front.  So when
   primary_part_structure[n] is free and primary_part_structure[n+1]
   contains a valid partition primary_part_structure[n] =
   primary_part_structure[n+k]

2. Why does it not work with logical partition?
   Because logical partitions have a different setup. Look at
   http://en.wikipedia.org/wiki/Extended_boot_record.  These partitions
   have no way of tracking the relation between the partition and the
   partition number (as opposed to the primary ones).  They are just a
   linked list and the first part in the list will be N and the next N+1
   and the next N+2....
   So since there is no way of tracking the relationship, parted
   (correctly) updates its internal structure by renumbering the
   parts.

3. Is there a way to make parted keep track of the part-number/partition
   relation ?
   IMO, yes.  But its something that is not worth considering because
   whatever strange numbering order we end up with, it will be lost on
   reboot.

4. Why is it lost on reboot?
   I believe that it is because the kernel just starts from the first logical
   partition and numbers from there.

5. What do you suggest to solve the referencing of a partition?
   To reference the partition (and anything on top of a real device) with start
   block and end block.  You will end up having to say something like
   getPartByGeometry(start, end).  FYI, parted already has this (or
   something very similar). With ped_disk_get_partition_by_sector,
   parted will return the partition that contains that sector.

If I am mistaken in any of this I would really appreciate a correction
:)

Regards.

On Fri, May 22, 2009 at 09:35:34AM -1000, David Cantrell wrote:
> On 05/22/2009 09:27 AM, Chris Lumens wrote:
>>> This is a hack that hans proposed for the parted issue.  Don't see this
>>> causing any problems.
>>> clumens: what do you think of this for a temporary solution for the
>>> enumeration issue?
>>
>> Applying this patch to parted in package CVS, adding the following patch
>> to pyparted, rebuilding both, and putting both in an updates.img fixes
>> the problem for me in my simple test case.
>>
>> diff --git a/src/pydisk.c b/src/pydisk.c
>> index 82500e5..84dcbd4 100644
>> --- a/src/pydisk.c
>> +++ b/src/pydisk.c
>> @@ -1403,6 +1403,9 @@ PyObject *py_ped_disk_remove_partition(PyObject
>> *s, PyObject *args) {
>>           }
>>       }
>>
>> +    if (ped_disk_enumerate_on())
>> +        ped_disk_toggle_do_enumerate();
>> +
>>       ret = ped_disk_remove_partition(disk, out_part);
>>       if (ret == 0) {
>>           if (partedExnRaised) {
>>
>> My simple test case is a partition layout with multiple logical
>> partitions.  Having that as a pre-existing layout and then doing
>> autopart consistently fails for me.  These patches correct that.
>
> The fix seems reasonable to me.  Existing API functionality is/can-be  
> preserved in libparted.
>
> In pyparted, I suppose we should also expose  
> ped_disk_toggle_do_enumerate(), but that's not critical for now.
>
> The libparted patch has my vote.
>
> -- 
> David Cantrell <dcantrell@xxxxxxxxxx>
> Red Hat / Honolulu, HI

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux