Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753673AbbFXQW5 (ORCPT ); Wed, 24 Jun 2015 12:22:57 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:34161 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752894AbbFXQWt convert rfc822-to-8bit (ORCPT ); Wed, 24 Jun 2015 12:22:49 -0400 MIME-Version: 1.0 In-Reply-To: <3819569.ix7n6b03GW@merkaba> References: <20150623182612.GA27461@rhlx01.hs-esslingen.de> <3819569.ix7n6b03GW@merkaba> Date: Thu, 25 Jun 2015 00:22:47 +0800 Message-ID: Subject: Re: Stop SSD from waiting for "Spinning up disk..." From: Jeff Chua To: Martin Steigerwald Cc: Andreas Mohr , Greg Kroah-Hartman , lkml , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2374 Lines: 70 On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald wrote: > Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du: >> Hi, > > Hi, > >> [proper In-Reply-To trail missing since lkml.org now fails to provide it] > […] >> > Greg, >> > >> > SSD is coming mainstream and it doesn't make sense wasting time >> > spinning up "disk" ... >> >> ...which probably is not truly being achieved >> by providing a *custom* kernel parameter >> which does apply to only those disk instances >> which some users *specifically* care about. >> >> Some things come to mind: >> >> - at this scope, generally spoken >> one shouldn't be concerned with whether "we are SSD", >> but rather whether "we (do not) need spinup" >> (which might apply to a ton of different SCSI-based storage devices, >> even some SAN-based platter-based ones) >> *This* is what this is about >> (and this could then have been reflected in kernel parameter naming) > […] >> - the kernel must already have some mechanisms to discern between >> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM >> command) > > Yep, for the first SSD in this laptop: > > merkaba:/sys> cat > ./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational > 0 It seems "rotational" is not reporting the correct status on USB devices ... # cat /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational 0 # cat sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational 1 # dmesg scsi host11: uas scsi 10:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6 # cat /sys/kernel/debug/usb/devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=152d ProdID=0567 Rev= 1.14 S: Manufacturer=JMicron S: Product=USB to ATA/ATAPI Bridge S: SerialNumber=3186E514500030 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 8mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas Both sda and sdb have the same SSD model. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/