On Mon, Jan 3, 2011 at 5:03 PM, Peter M. Petrakis <peter.petrakis@xxxxxxxxxxxxx> wrote: <snip> >> Thanks. I have a client that needs to recognize SSDs from userspace >> and I missed the ABI. >> >> I was looking for the userspace ABI to be in /sys/block like the >> topology stuff is, so I missed the userspace ABI and was confused. > > Ah you mean /sys/block/sda/queue/rotational. I missed that one. Never thought to look in queue. :( (I don't know what SSD has to do with queue, but okay. Please don't answer, I've read some of the discussion before and promptly forgot it.) In the mean time I've found the hdparm also looks at word 217 and reports SSD devices. It has apparently been doing that since v9.12 or so. (spring 2009). My current concern is that the logic is slowly diverging between the kernel 2.6.36 implementation and the hdparm v9.36 implementation. Mark (added to cc), Would it be better if hdparm looked at /sys/block/sda/queue/rotational instead of just using word 217 of the identify block? The current divergence is: 1) The kernel routine ata_id_rotation_rate() (in ata.h) is only trusting word 217 if its ATA7 or higher. http://lxr.linux.no/#linux+v2.6.36/include/linux/ata.h#L799 2) There have been a couple proposed kernel patches to libata-scsi.c to quirk in a HORKAGE flag to set the rotation_rate to 1 (meaning SSD) for some known devices. I don't see those being ACKed yet, but if one ever gets in, hdparm will diverge from the kernels info since its going straight to the identify block for its info. Or is queue_flag_set_unlocked(QUEUE_FLAG_NONROT, q) somehow setting word 217 for future identify block usage by hdparm? (I have no idea what that call does. It was in Bart's ATANG patch, but not Peter's.) Bart's atang PATCH: http://marc.info/?l=linux-ide&m=126677421807814&w=2 Peter's patch: http://www.spinics.net/lists/linux-ide/msg38944.html I hope one of the approaches goes in. As I said I have a userspace app that really needs to know if its talking to a traditional rotating device or a SSD, so I suspect we'll be sending in quirk patches as we start lab testing devices. Thanks Greg -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
