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 > general? 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: > > > http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ 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 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. _______________________________________________ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel