From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: Is there a reliable way to ID a SSD? Date: Tue, 04 Jan 2011 10:47:59 -0500 Message-ID: <4D23412F.2080802@teksavvy.com> References: <4D2223BF.8090901@canonical.com> <4D2247A3.2060506@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ironport2-out.teksavvy.com ([206.248.154.183]:2901 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751719Ab1ADPsP (ORCPT ); Tue, 4 Jan 2011 10:48:15 -0500 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Greg Freemyer Cc: "Peter M. Petrakis" , IDE/ATA development list On 11-01-03 05:50 PM, Greg Freemyer wrote: > > 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. That's what hdparm is for. It reads only from the identify block for most of the -I output, so that we (kernel developers) can see exactly what the drive itself is reporting. This reporting is what makes it useful, rather than simply parroting whatever is already reported (or not) in /sys/ Cheers