[parted-devel] [rfc] SSD partition alignment
jim at meyering.net
Sun Feb 22 11:39:46 UTC 2009
Colin Watson wrote:
> On Sun, Feb 22, 2009 at 01:40:16AM +0100, Jim Meyering wrote:
>> Daniel J Blueman wrote:
>> > I've checked into this, and since libparted sees the SATA block device
>> > as SCSI, it doesn't perform the expected ATA 'identify' command to
>> > fill out the 512 bytes of device info, of which (short) word 217 is
>> > device RPM, defined to be 1 on newer compliant SSDs. The kernel uses
>> > this word to detect if a device is an SSD or not, so I suggest we use
>> > the same.
>> > Anyone think of objections to calling the ATA identify ioctl to fill
>> > out the structure, then storing this flat for later use in constraint
>> > checking? If the SCSI device supports it also, fine, else nothing
>> > lost.
>> > For now, a 1MB starting offset for an SSD seems safest, and is what MS
>> > Windows 7 and Server 2008 use, thus a number of vendors will also be
>> > testing/optimising with this case too.
>> Does this really need to be SSD-specific?
>> I hear that this (alignment) is high priority also for many
>> of the big new disks, since they have 4k-byte sectors.
>> Without better alignment, their performance will suffer, too.
> Well, one step at a time. We can detect SSD; can we detect those big new
> disks (or, in general, the desired sector size)?
Alignment-related changes that are useful for SSDs will also benefit
other hardware, so we'd be remiss not to consider that up-front.
I think we agree:
Writing a "device-is-an-SSD" function that queries the kernel, and
then having some caller use that to look up reasonable-for-SSD
alignment parameters would be useful. Just make it general
enough to also work with e.g., a "device-has-4kb-sector" function.
However, I'm beginning to wonder if that'd be more appropriate
at a higher level than parted, like in gparted. More below.
> Or are you saying that we should increase the alignment to 4KB in
Changing the default for both interactive and -s might be easiest,
but IMHO, that is not an option.
> It seems that SSDs actually really want 128KB, which starts to
> feel like a bit much to apply to all disks:
Yes, I read that, too.
And so have others, which prompted some IRC discussion Friday morning.
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?
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
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.
More information about the parted-devel