On Fri, Jan 23, 2009 at 1:56 PM, Colin Watson <cjwat...@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-t...@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 _______________________________________________ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel