[parted-devel] [rfc] SSD partition alignment

[Daniel J Blueman]

On Sun, Feb 22, 2009 at 1:53 PM, Jim Meyering <jim at meyering.net> wrote:
> Daniel J Blueman wrote:
> ...
>>> But let's back up a step.
>>> Do we really need to change anything?
>>> Or are you proposing (like I think Eric was) a way to
>>> make this merely more convenient?
>>
>> The question is: will the average user know and be prepared to do
>> this? Probably not, so will experience a performance/longevity penalty
>> which could have been avoided perhaps...
>
> I sincerely hope that the average user does not use parted ;-)
> Even for those of us who have braved its murky depths, sometimes
> it's hard to remember (or discover) how to do things the parted way.
>
>>> 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.

Yes, perhaps Matt Domsch's work is on the right lines, or no?

http://www.mail-archive.com/parted-devel@lists.alioth.debian.org/msg02168.html

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

Agreed; though it seems sensible to integrate as much of this into
libparted and ensure the applications use the constraints, rather than
duplicate the work in all the users of libparted:

$ apt-cache rdepends libparted1.8-9
[trimming list]
  qtparted
  kvpm
  gnu-fdisk
  fatresize
  ubiquity
  parted
  gparted
-- 
Daniel J Blueman