[parted-devel] [rfc] SSD partition alignment

[Daniel J Blueman]

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>
-- 
Daniel J Blueman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gparted-alignment.diff
Type: text/x-diff
Size: 20869 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20090223/0ce63bc9/attachment-0001.diff