Re: [PATCH 1/1] Make sure that forced primary partition are first.

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

 



On Fri, 2009-04-24 at 18:31 +0200, Joel Granados Moreno wrote:
> In the new_partitions list (partitioning.py:617) we must make sure that
> the forced primary partitions appear first so we don't end up trying to
> put a primary partition in an extended one in partitioning.py:696.
> (#493058)

I don't see how this relates to the bug you referenced, although I
realize you have looked more deeply than I have. Still, I think if this
was a matter of sorting requests we would get a normal failure to
allocate (not enough space or similar).

It seems at first glance like we are adding multiple devices with the
same path to the device tree, which is a different matter entirely as I
see it. How did you get to partition request sorting from there?

> ---
>  storage/partitioning.py |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/storage/partitioning.py b/storage/partitioning.py
> index 663d1f1..5c028d0 100644
> --- a/storage/partitioning.py
> +++ b/storage/partitioning.py
> @@ -366,12 +366,12 @@ def partitionCompare(part1, part2):
>      # bootable partitions to the front
>      ret -= cmp(part1.req_bootable, part2.req_bootable) * 1000
>  
> +    # primary-only to the front of the list
> +    ret -= cmp(part1.req_primary, part2.req_primary) * 600
> +
>      # more specific disk specs to the front of the list
>      ret += cmp(len(part1.parents), len(part2.parents)) * 500
>  
> -    # primary-only to the front of the list
> -    ret -= cmp(part1.req_primary, part2.req_primary) * 200
> -
>      # larger requests go to the front of the list
>      ret -= cmp(part1.req_base_size, part2.req_base_size) * 100
>  

This makes me very nervous. Even if the change is justified, the way I
chose the scores/weights is such that the sum of all lower scores cannot
overturn a higher score. At the very least you want to maintain this by
shifting the scores accordingly.

This change would require a great deal of testing to make sure it
doesn't break other cases. We need to be sure it is the best fix for the
problem before we go changing something so central to how partitioning
works.

Dave


_______________________________________________
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