[parted-devel] [rfc] SSD partition alignment

[Curtis Gedak]

Jim Meyering 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.

For a disk that already contains a partition, my thought is that the 
default alignment algorithm should match the way the first partition is 
aligned.  By this I mean if the first partition uses cylinder 
boundaries, then the default alignment for new partitions would be by 
cylinder alignment.

If the first partition uses this new 1MB alignment, then new partitions 
would also use the 1MB alignment scheme.

In the case of a disk containing no partitions, my thought is to default 
to using the 1MB partition alignment scheme, because modern disks often 
do not physically match the C/H/S reported (ie., xxx/255/63).

Does the above 1MB alignment scheme sound logical, or have I missed 
something important?

Regards,
Curtis Gedak
Maintainer of GParted