Bug 410011

*** Bug 441424 has been marked as a duplicate of this bug. ***

Have you encountered the same problem in Fedora 9?

Hi,

I looked at anaconda for a while and found the sort that changes the order of
the partitions.

I AM NOT a python guy. 

Why is the partition map even sorted at all?

I can try to find my info on this if you really want it. I did the research a
long time ago... around fc 5 era or maybe rhel 3. Yes! It's been a thorn in my
side for a LONG time too. :-(

Regards,

George...

(In reply to comment #2)
> Have you encountered the same problem in Fedora 9?

Yes.

When installing RHEL5, I added several lvm logical volumes in Disk Druid in the
following order:

swap  2048M
/     1024M
/usr  4092M
/tmp  512M
/var  10240M
/home 20480M

But anaconda actually created the logical volumes in the following order:

/
/home
/usr
/var
/tmp
swap

As I recall, anaconda has had this problem since the old days of rh5/6. When I
wanted to create partitions in my prefered order, I had to switch to the
console, and partition the hardisks manually beforehand.

IMHO, anaconda should preserve the partition ordering as entered, and ideally,
Disk Druid should allow users to move up and down partitions/raid/volumes.

*** Bug 453813 has been marked as a duplicate of this bug. ***

Do "we" have a current status on this bug?

I REALLY object to it's classification of low in priority. I have had to jump through hoops to get around this problem. The research I have done shows a sort of the partition table with makes absolutely NO SENSE TO ME. Why is the sort even being done?

As for answering the question of Fedora Core 9, I tried installing and running FC9 for a few weeks and found it WOEFULLY deficient in functionality.

Thanks!

George...

(In reply to comment #7)
> I REALLY object to it's classification of low in priority. 

I am unsertain if it should be me (as the reporter) or the assigned group that should escalate the classification.

Bjørge

(In reply to comment #8)
> (In reply to comment #7)
> > I REALLY object to it's classification of low in priority. 
> 
> I am unsertain if it should be me (as the reporter) or the assigned group that
> should escalate the classification.
> 
> Bjørge

Bjorge,

I am CERTAIN that my comment was addressed to the assigned group for this bug. 

I apologize if I have mis-directed my comment on this bug.

Regards,

George...

Oh, that I got, I just wondered if it was apropriate for me, who set it to low in the first place when I reported it, to bump it up as no maintainer seems to look at this. I just set it to medium. If that was not for me to do, I politely ask the maintainer(s) to set it to low again.

Bjørge

What are you trying to solve by putting the partitions into a specific order?  I think for the typical use case, most people really don't care, and adding widgets into the UI is going to make things even more complicated than they already are.  The partitioning code as it exists today is in a bit of a holding pattern, so we are unlikely to even consider working on this for quite a while.

For the kickstart case, you can easily add your partitions exactly the way you want them with a %pre scripts and then use --onpart for your various partitions.  We've provided all the capability to do this sort of complicated partition manipulation, you just have to put the pieces together.

When setting up RAID and making one disk a clone of another, I want the disks to be identical. I want /dev/md0 to be comprised of /dev/sda1 and /dev/sdb1 -- I don't want it to be /dev/sda1 and /dev/sdb3. Because that's just going to confuse the hell out of me if I ever have to do any maintenance.

I have a machine with DMA problems which with recent (libata) kernels has taken to kicking one device out of the RAID1 every time it boots, before it falls back to using PIO. So I'm _often_ re-adding devices to the RAID. And if those had random partition numbers I'd have screwed it up by now.

1. The disk throughput at outer cylinders is faster than that at inner cylinders. So it's a good idea to put swap at the outer cylinders.

2. To reduce unnecessary seek time, it's advisable to put the biggest partition at the end.

Another anaconda problem that I encountered the other day (It is unrelated to this bug, but I don't feel like filing a new bug because I don't have access to this machine now):

The default partition scheme of anaconda doesn't work for a server machine with 600+GB RAID storage. LVM fails when creating the last swap partition, because there is not enough disk space.

To workaround the installation failure, I had to modify the default partition scheme so that a little disk space is left unused.

There is definitely rounding bug with disk space calculation in anaconda.

Howdy,

Let me say this. I STRENUOUSLY object to this closure. This "feature" is indeed a bug.

I ask you, where is the logic of sorting the entries? 

It is implied by the partitioning process that what you ask for IS what you get. Yes? NOT some programmers idea of what the user "should" want or "should" do. You have NO idea what any user wants to do or why and unless you ask them you'll never know. You can make recommendations which is helpful if only to present a differing viewpoint, but "we" are NOT required to follow those recommendations. To force your own concept of what should or shouldn't be done isn't reasonable.

I have found that if you tell your customer no too many times, they'll go somewhere else. I'm sure that RedHat doesn't want this to happen.

George...

(In reply to comment #11)
> For the kickstart case, you can easily add your partitions exactly the way you
> want them with a %pre scripts and then use --onpart for your various
> partitions.  We've provided all the capability to do this sort of complicated
> partition manipulation, you just have to put the pieces together.

I have around 500 running clients and 200 laptops coming soon. Having different partition sheme on these is asking for trouble. I actually do what you suggest today, but the code is UGLY:

## START CODE snippet

 standard )
  echo " - standard partitioning - overwrite everything"
  #remove existing partitions
  #lets choose the first disc:
  pdisk=`cat /proc/partitions | tail -n +2 | sed -e 's/^.* //' | grep '[^0-9]$' | head -1`
  #wipe partition table
  dd if=/dev/zero of=/dev/$pdisk bs=1k count=1000
  #create partitions
  ( echo "n" ; echo "p" ; echo "1" ; echo "1" ; echo "32" ; 
      echo "n" ; echo "p" ; echo "2" ; echo ; echo "+40000M" ; 
      echo "n" ; echo "p" ; echo "3" ; echo ; echo "+2048M" ; 
      echo "n" ; echo "p" ; echo ; echo ;
      echo "t" ; echo "1" ; echo "6" ;
      echo "t" ; echo "3" ; echo "82" ; echo "w" ) | fdisk /dev/${pdisk}
  parted -s /dev/${disk} mkfs 1 fat16 
  parted -s /dev/${disk} mkfs 2 ext2
  cat > /tmp/partition.inc << __EOF__
#Disk partitioning information
part /reboot --noformat --onpart=${pdisk}1
part / --fstype=ext3 --onpart=${pdisk}2 
part swap --onpart=${pdisk}3
part /scratch --fstype=ext3 --onpart=${pdisk}4

## END CODE

Then I include /tmp/partition.inc later on. Not pretty at all, and far from easy to maintain.

My point is that I would not have to do this if the sorting was removed. I have talked with people at RedHat who think this is an undesired "feature", why you insist on keeping it I cannot comprehend. The RedHat employee actually incuraged me to file this bug. I might as well file it under RHEL because it exists there too.

Can I make a suggestion for change? Move the sorting to the UI, that way it will not affect kickstart installations, and at the same time sort the partition table nicely for the average user.

(In reply to comment #13)
> 1. The disk throughput at outer cylinders is faster than that at inner
> cylinders. So it's a good idea to put swap at the outer cylinders.

Some disks map the cylinders starting from the inside, and some map them starting from the outside.  Reliably determining this is... non-trivial at best.

I'd rather just let the user decide.  If they happen to pick something sub-optimal the difference still won't be very bad on modern hardware.

(In reply to comment #14)
> Another anaconda problem that I encountered the other day (It is unrelated to
> this bug, but I don't feel like filing a new bug because I don't have access to
> this machine now):

Please file a separate bug for this. It will more than likely not get dealt with if it is not in its own report.

(In reply to comment #15)
> Howdy,
> 
> Let me say this. I STRENUOUSLY object to this closure. This "feature" is indeed
> a bug.

We're planning on totally rewriting the partitioning code in the near enough future that there isn't much reason to take care of this now - it's a lot of work to put into something that's going to be thrown out.

(In reply to comment #19)
> Please file a separate bug for this. It will more than likely not get dealt
> with if it is not in its own report.

Bug #460602.

Just saw this behavior in a RHEL 5.4 install (anaconda-11.1.2.168-1). I am frankly a little shocked, we are publishing a paper in USENIX FAST this year about how disk performance on outer platters can be 2x faster and how to structure high-volume data analysis code to take advantage of this fact. How you find out which partition actually lands on the outside of the platter is your problem, but when you do, you want anaconda to respect your ordering!

Regarding comment#19, "Re-writing the code in the near future" is not comforting. We've been around enough to know how accurate "near future" is, and not to rely on it. For serious users, and I thought RHEL catered to this demographic, partition order matters in certain cases, and this is still not fixed. 

I am going to patch anaconda to remove the sort. George, re comment#7, do you have the filename and line number? Might save me some time.

Federico

I am currently using a CentOS 5.4 system. I can look for this and let you know what I find. Ok with you?

George...

(In reply to comment #19)
> We're planning on totally rewriting the partitioning code in the near enough
> future that there isn't much reason to take care of this now - it's a lot of
> work to put into something that's going to be thrown out.  

Is the code replaced in fedora 10, 11 or 12?

Regards
Bjørge

In my version of anaconda (see comment#21) the following edits fix this problem so that the intended order of partitions is preserved.

COMMENT OUT THE FOLLOWING SORTS
1. partitions.py:466 in Class Partitions, method addRequest(). 
2. autopart.py:926 in processPartitioning() calls requests.sortRequests() before it starts making partitions. 

Another sort in partitioning.py:75 does not need to be commented out.

Federico,

You are the MAN!

Is the software you changed available for testing by any chance?

GOOD WORK!

Regards,

George...

Thanks. Re available, not easily, however using RedHat's nice product.img structure patching anaconda is simple. Make a directory like squashfs_product/, somewhere, put copies of the files from comment#24 in it (at the top level), make the edits, then create a sqashfs disk image using the command below, put it on your kickstart server so an installing host gets it, and done.

mksquashfs squashfs_product/* product.img -keep-as-directory