[parted-devel] [rfc] SSD partition alignment (was: Jaunty experience and SSDs)...

[Daniel J Blueman]

On Fri, Jan 23, 2009 at 1:56 PM, Colin Watson <cjwatson at ubuntu.com> wrote:
> On Fri, Jan 23, 2009 at 12:04:33AM +0000, Daniel J Blueman wrote:
>> In order to maximise user experience thus performance, we need to
>> ensure the disk partitions created on SSDs/USB flash drives/RAID
>> arrays are 4KB (perhaps up to 128KB) aligned. There are considerable
>> benefits with the flash/RAID controller opening half as many
>> pages/stripes on small reads. This pays better with slower SSDs in eg
>> netbooks.
>>
>> Patches have entered the upstream kernel to detect when drives are
>> solid-state [1], though the dust hasn't settled on the interface.
>>
>> How acceptable would getting the userspace partitioner changes into
>> Jaunty if proven to be stable and robust?
>
> This seems like something that could be added as a libparted constraint
> without *too* much pain. If and only if the corresponding kernel changes
> go into the Ubuntu kernel (work with kernel-team at lists.ubuntu.com, I
> think), I agree that we should change the partitioner too, and pass the
> changes to parted upstream, although I would add that the changes need
> to be reasonably simple and elegant as well as stable and robust; I only
> like partitioner code that I can understand. :-)

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.

Daniel
-- 
Daniel J Blueman