Red Hat Bugzilla – Bug 115166
Bad partitionning by anaconda
Last modified: 2007-11-30 17:10:36 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: When I choose to partition MANUALLY through anaconda the end result respect my wishes for partition sizes but the layout I get is both different than the one I gave and IMHO grossly suboptimal. Tracks in the outer ridge (low numbered tracks) have more blocks than tracks in the inner ridge. For that reason they are faster and should be used for the partitions who will see the heaviest use. But when I partition with anaconda I find the boot partition at the very first (that is OK since it is an architectural constraint) and partitions I consider unimportant at the beginng while the important ones are at the end in the slowest part of the disk. (it seems to use a kind of LIFO stack) When user selects to partition manually Anaconda should step aside since it cannot guess what will be the important partition (/usr for a developer machine, the one containing the database for an Oracle server) Version-Release number of selected component (if applicable): 9.2 How reproducible: Always Steps to Reproduce: 1. Install any RedHat or Fedora version 2. Choose to partition manually through Disk druid 3. Actual Results: Partitions in LIFO order Expected Results: Partitionning accrding to my wishes Additional info:
Partitions are ordered by size (with exceptions) so that growing can fill the disk in a sane fashion. If you want more explicit partitioning, you can choose to edit the free space and set partitions in explicit cylinder ranges.