[parted-devel] [rfc] SSD partition alignment

[Daniel J Blueman]

On Mon, Feb 23, 2009 at 11:06 PM, Curtis Gedak <gedakc at gmail.com> wrote:
> 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
>>>>>> 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 drives
>>> too.
>>>
>>> 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.
>>
>> Thanks,
>>  Daniel
>>
>> 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 discussion there.

> COMMENTS:
>
> 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 possible.
>
> 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.

I was weighing up changing the radio button to a spin button for other
alignments, but then we could equally allow eg 128KB alignment, thus
the UI complexity and user decisions paths complicate, which is good
to avoid. I also agree with your point though.

> 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
> Else
>    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.  :-)

I do think it makes sense having it in libparted, however it's clear
alignment is implemented and conflicts in both gparted and libparted.

> 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 each language.
> See the following link:
> http://l10n.gnome.org/module/gparted/

Good tip and thanks for the feedback,
  Daniel
-- 
Daniel J Blueman