partman changes for parted 2.2
As part of the transition to parted 2.2, I made a few changes to
partman-base to take advantage of its new facilities. I'm sending a
description here since they're non-trivial.
partman-base (140) unstable; urgency=low
* Don't warn about data loss on formatted/removed partitions when there
are no such partitions (LP: #151266).
* Build against parted 2.2.
* Use linux-swap(v1) instead of linux-swap(new) to reflect changes to
parted (thanks, Evan Dandrea; closes: #539908).
* Apply optimal alignment constraints to new partitions, or when
maximising an extended partition (LP: #530071).
* Add an ALIGNMENT_OFFSET command which can be used to detect whether a
partition is misaligned.
[ Updated translations ]
* French (fr.po) by Christian Perrier
* Lithuanian (lt.po) by Kęstutis Biliūnas
-- Colin Watson <cjwatson@debian.org> Sun, 21 Mar 2010 23:47:56 +0000
Hard disks are moving towards shipping with non-512-byte physical
sectors (the marketing term seems to be "Advanced Format" at least in
some quarters), for improved performance and capacity. This is distinct
from a change in the *logical* sector size, which is more invasive and
thus less popular for the time being. Physical sector size denotes how
sectors are actually laid out on disk; logical sector size denotes the
transfer unit between the disk and the OS. At the moment logical
sectors tend to still be 512 bytes to facilitate the transition to
larger sectors, although we shouldn't bank on it being this way forever.
For a good summary with interesting links, see LWN's weekly kernel
summary from the week before last:
http://lwn.net/Articles/377392/
I'd appreciate it if people followed through some of the links there
before following up here; Tejun Heo's summary in particular is well
worth reading.
The most significant change in partman-base 140 is this one:
* Apply optimal alignment constraints to new partitions, or when
maximising an extended partition (LP: #530071).
The effect of this will tend to be, on most disks, that partitions are
aligned on 1MiB boundaries. partman operates in megabyte units anyway,
so I don't expect the extra "wasted" space to be a major problem,
particularly given the size of today's disks. Cylinder alignment (first
partition starting at sector 63) hasn't been a performance advantage for
many years as I understand it, and 1MiB alignment has more modern
performance and compatibility advantages, so I definitely think it makes
sense as a default. Note that libparted will return more specific (and
sometimes weaker) alignment if the disk exposes that information; 1MiB
is just a default.
Caveats which may require further work before squeeze:
* Given rumours that Windows XP has trouble with non-cylinder
alignment (the exact situation is unclear to me, and I haven't been
able to find an authoritative statement), and out of general
paranoia, we probably ought to make this adjustable by way of
preseeding. The partition_creation_constraint function is
abstracted with a view to adding this, but I haven't done it yet.
Something like partman/alignment=cylinder/minimal/optimal seems to
make sense, matching parted's own facilities.
* I'm not sure whether this makes sense on all architectures /
partition table types. Porters, please comment, preferably after
basic testing. Given a preseedable adjustment, we could make the
default alignment architecture-specific or something.
* Do bootloader-type partitions at the very start of the disk really
need to be aligned? For example there doesn't seem to be a
particular need to align a bios_grub partition, and it would save a
megabyte if we didn't. This is a first cut ...
* I added an ALIGNMENT_OFFSET command with a view to being able to
warn when you reformat an existing partition that's misaligned
relative to the disk topology, since that might be a good
opportunity to realign it and it's probably hideously painful to
realign at any other time. I haven't implemented the higher layers
of this yet.
* Any new bugs, obviously. I really don't want us to ship squeeze
with seriously suboptimal partitioning for new drives, but by the
same token don't want to break older hardware.
Comments welcome,
--
Colin Watson [cjwatson@debian.org]
Reply to: