[parted-devel] [rfc] SSD partition alignment

Tue Feb 24 21:17:11 UTC 2009

Daniel J Blueman wrote:
> 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.
>
>   
I hadn't thought about a spin button.  That would certainly open up more 
possibilities without complicating the user interface too much.
>> 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
>