[parted-devel] [rfc] SSD partition alignment

[Curtis Gedak]

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.

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


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/