[parted-devel] [rfc] SSD partition alignment
gedakc at gmail.com
Sun Feb 22 17:01:00 UTC 2009
Jim Meyering wrote:
>>> I can already create partitions aligned to 128KiB boundaries.
>>> This creates a first partition of just less than 1GiB,
>>> and the second taking up the remainder of the space
>>> and also using a size that's a multiple of 128KiB:
>>> dev=file; : > $file
>>> k=1024 m=$(($k*$k)) g=$(($k*$k*$k))
>>> dd if=/dev/null of=$dev bs=1 seek=32GiB
>>> parted -s $dev mklabel gpt
>>> parted -s $dev u B mkpart primary $((128*$k)) $(($g-1))
>>> parted -s $dev u B mkpart primary $g $((32*$g - $m - 1))
>>> parted -s $dev u B p
>>> Model: (file)
>>> Disk /t/file: 34359738368B
>>> Sector size (logical/physical): 512B/512B
>>> Partition Table: gpt
>>> Number Start End Size File system Name Flags
>>> 1 131072B 1073741823B 1073610752B primary
>>> 2 1073741824B 34358689791B 33284947968B primary
>>> Now, I think that this functionality
>>> (snap-to-user-specified-or-system-derived-alignment) belongs in gparted,
>>> and not in parted.
>> Yes, if we propose to add an option to say "tick, I know I have an
>> SSD", but this adds more unnecessary user complexity, when the cost to
>> non-SSDs is so low.
>> What's (at worst) 128KB slack in partition layouts, when we already
>> skip the first 63 sectors anyway?
> If that were the only cost, we'd switch right away.
> However, parted's code is very fragile, and changing how it handles
> constraints/alignment seems like it'd be very risky. Why go there
> if it's not absolutely necessary? Besides, the functionality I think
> you want (to make the process convenient or mandatory) belongs in a
> higher-level tool.
> If the programmers and tools invoking parted cannot be bothered to
> do a little modulo arithmetic and be aware of alignment, then they
> shouldn't be choosing partition boundaries in the first place.
Changing GParted to align to boundaries different that the old cylinder
alignment scheme is definitely possible, and probably desirable. This
would provide the alignment performance benefits to a large group of
people, and still allow experts to use tools such as fdisk, or parted to
hand craft their own partition boundaries.
Since Vista appears to be going to a 1MB boundary, it may be beneficial
to adopt this as the new boundary standard. And since 1 MB is evenly
divisible by 4kB and by 128kB, this should satisfy
current and some potential future performance requirements. I believe
this solution should work well on current hard drives, and solid state
My assumption is that a 1MB boundary would be used for all partition
tables, including MSDOS and GPT. Hence MSDOS would reserve 1MB at the
start of the disk for the boot record, and GPT would do the same. MSDOS
would also reserve 1MB at the front of each logical partition.
For a disk that already contains a partition, my thought is that the
default alignment algorithm should match the way the first partition is
aligned. By this I mean if the first partition uses cylinder
boundaries, then the default alignment for new partitions would be by
If the first partition uses this new 1MB alignment, then new partitions
would also use the 1MB alignment scheme.
In the case of a disk containing no partitions, my thought is to default
to using the 1MB partition alignment scheme, because modern disks often
do not physically match the C/H/S reported (ie., xxx/255/63).
Does the above 1MB alignment scheme sound logical, or have I missed
Maintainer of GParted
More information about the parted-devel