[parted-devel] [rfc] SSD partition alignment
Daniel J Blueman
daniel.blueman at gmail.com
Sun Feb 22 14:19:43 UTC 2009
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?
> 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
Daniel J Blueman
More information about the parted-devel