Re: Non-deterministic ordering of raid partition creation...

[Jeremy Katz <katzj redhat com>]

On Wed, 2006-12-13 at 13:11 -0500, James Olin Oden wrote:
> On 12/13/06, Jeremy Katz <katzj redhat com> wrote:
> > On Wed, 2006-12-13 at 09:44 -0500, James Olin Oden wrote:
> > > I might be able to live with this, but again I ask is this desirable
> > > behavior?  I can see after thinking through this a bit how in the case
> > > where you were installling over an existing system and partitions were
> > > not being cleared that there would have to be a bit more flexibility
> > > as to the ordering of partitions, but I would have assumed that when
> > > the partitions were cleared, you would end up with same order as was
> > > specified in the kickstart file (implicitly via the order of the part
> > > declerations in the kickstart file)?  Is this not a reasonable
> > > assumption?
> >
> > The ordering is deterministic, but it doesn't necessarily match the
> > order that they're specified in.  Due to wanting to be able to support
> > partitions with --grow, the general way things work is that we allocate
> > the biggest partitions first and then go down in size from there.[1]
> >
> > [1] There's an exception that makes sure we allocate boot partitions
> > first taking into account that different arches have different
> > constraints.
> OK that makes sense...in my case I can live with that, but wouldn't it
> also make sense to have the ability to allow the user to specify the
> order of the partitions (similar to --onpart, but the partition does
> not have to exist)?

It's actually remarkably non-trivial to do so with the way that
libparted works.  It also makes things very complicated to present to
the user due to differences in partition tables across arches.

> Which ananconda file would I need to change to develop a patch to
> provide for this (I already figure I would have to start in
> kickstart.py but I still have not located the sort algorithm (though I
> think I might have looked at it and did know what I was looking at))?

All the magic for this is hidden away in autopart.py

Jeremy