Bug#595818: marked as done (partitioner (IBM-PC) force geometry to one friendly to SSD, 4KiB sectors and RAIDs)
Your message dated Tue, 7 Sep 2010 22:12:57 -0300
with message-id <20100908011257.GA32477@khazad-dum.debian.net>
and subject line Re: Bug#595818: partitioner (IBM-PC) force geometry to one friendly to SSD, 4KiB sectors and RAIDs
has caused the Debian Bug report #595818,
regarding partitioner (IBM-PC) force geometry to one friendly to SSD, 4KiB sectors and RAIDs
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact email@example.com
Debian Bug Tracking System
Contact firstname.lastname@example.org with problems
--- Begin Message ---
The current IBM-PC style partitioner uses the no-good 255 heads, 63
sectors/track default format from 20 years ago, which misaligns
partitions on just about every device (logical or hardware) that has a
reason to care about something other than 512 bytes.
This results in severe performance degradation on the new HDs (4096-byte
sectors exposed as 512 byte sectors), extra wear on SSDs (64, 128, 256
and 512KiB erase blocks), and RAID volumes (both hardware and software,
64, 128, 256 and 512KiB stripe sizes).
Please consider forcing the partition tools to do something sensible.
The most effective way is to just align everything to 1MiB, ignoring
One can also use a less cubersome number of heads and sectors than the
default 255/63, to get better alignment. If a BIOS will break with the
unaligned LBA-only partitions, it will also break with this and also
have LBA32/LBA48 issues anyway, so this is not a "better compatibility
choice" as far as the BIOS goes. The only advantage is that fdisk won't
give you any crap about the alignment.
Using 224 heads and 56 sectors per track will work for the 64KiB and
128KiB stripe sizes/erase block sizes, as well as 4KiB sectors.
Using 224 heads and 48 sectors per track will work with all of the
above, and also 256KiB stripes/erase blocks.
Using 224 heads and 32 sectors per track will work with all of the
above, and also 512KiB stripes/erase blocks.
Windows deals with all of the above options just fine, AFAIK.
Linux-only boxes should be using GPT anyway, but unless we are going to
suggest that to the user, we should try to do better on our IBM-PC
Note that forcing LVM to align its metadata area is also necessary last
time I checked. Its default alignment (192KiB) is good only for 64KiB,
one needs to force it to 256KiB (for 64 to 256KiB stripes/erase blocks)
or 512KiB (for 64 to 512KiB stripes/erase blocks) to get proper
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 22.214.171.124 (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
On Tue, 07 Sep 2010, Christian PERRIER wrote:
> Dealing with alignment stuff has been introduced in partman-base 140
> and enhanced in later versions.
> If you were using a weekly built netinst image (that includes d-i
> alpha1 released in Feb. 2010), you may be using an earlier version.
> Can you try the latest *netboot* daily builds from
> http://www.debian.org/devel/debian-installer? Installing squeeze with
> these should use the latest partman-base and give what you expect (at
> least I think: I know nothing to these things, I'm just guessing from
I can confirm partman is aligning things properly for IBM-PC labels, and it
is using 1MiB as the target, which is very good (and matches what Windows
does nowadays as well).
I will close the bug.
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
--- End Message ---