[parted-devel] [rfc] SSD partition alignment
gedakc at gmail.com
Mon Feb 23 23:06:34 UTC 2009
Daniel J Blueman wrote:
> On Sun, Feb 22, 2009 at 5:01 PM, Curtis Gedak <gedakc at gmail.com> 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
>>>>> 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 drives
>> 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.
> The attached and tested patch (against gparted 0.4.3) replaces the
> 'Round to cylinders' checkbox with 'Round to megabytes' (the 1990s is
> finally over), though it doesn't indicate why one may select it. Let
> me know if 'Performance (megabyte) alignment' or such is preferred.
> I have corrected the incorrect rounding logic, which was passing
> potentially overlapping partition data to libparted. However, all is
> not done since libparted's default constraints defeat the alignment,
> but it does what is needed for the GParted component; I'll look at
> getting a patch together for libparted. The translations need
> updating, but this is clear with the updated English strings.
> commit info:
> Replace option to perform cylinder-alignment by megabyte-alignment,
> useful for avoiding performance and longevity loss on storage arrays
> and SSD disks.
> Signed-off-by: Daniel J Blueman <daniel.blueman at gmail.com>
Thank you Daniel for the effort you took to create a patch for GParted.
I can tell that this is an important issue to you, and I agree that it
is one that should be addressed.
Following are my comments with regards to the patch.
These comments are not all parted-devel specific items, but may be
useful for others reading this thread. If desired by the parted
developers, we can open a new bug for GParted and continue the
1) I think it is important to continue to support the older C/H/S
rounding. It might not be as applicable with today's hard drives, but I
strongly believe in maintaining backward compatibility as much as is
To implement such support, I think the GParted GUI would need radio
buttons to permit the user to choose either "Round to cylinders" or
"Round to megabytes". Another radio button might be required for
"strict sector values" because GParted currently implements these.
Default values for the radio buttons could be determined as follows:
If no partitions exist on the device then
default to use round-to-megabytes
Else if the first partition uses cylinder boundaries then
default to use round-to-cylinders
default to use round-to-megabytes
NOTE: If the megabyte partition boundary logic is to be built into
libparted, then it might be better to enhance GParted to use this new
libparted logic. That way there would be less chance of differing
results between any GParted logic, and the libparted logic. :-)
2) As a general rule with GParted, I leave the updating of all language
translations to the GNOME Translation Teams. If the *.po file updates
were committed, then the translation tracking would falsely represent
that the string "Round to megabytes" had been properly translated in
See the following link:
More information about the parted-devel