Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933164AbbFWS0T (ORCPT ); Tue, 23 Jun 2015 14:26:19 -0400 Received: from rhlx01.hs-esslingen.de ([129.143.116.10]:46959 "EHLO rhlx01.hs-esslingen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753235AbbFWS0N convert rfc822-to-8bit (ORCPT ); Tue, 23 Jun 2015 14:26:13 -0400 Date: Tue, 23 Jun 2015 20:26:12 +0200 From: Andreas Mohr To: Jeff Chua Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Christoph Hellwig Subject: Re: Stop SSD from waiting for "Spinning up disk..." Message-ID: <20150623182612.GA27461@rhlx01.hs-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT X-Priority: none User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2832 Lines: 75 Hi, [proper In-Reply-To trail missing since lkml.org now fails to provide it] > On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman > wrote: > > On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote: > >> > >> There's no need to wait for disk spin-up for USB SSD devices. This > >> patch > >> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 > >> during > >> boot-up. > >> > >> If there's a better way to handle this, please share. > > > > Module parameters are never a solution for a device-specific property, > > sorry. This statement, while somewhat harsh, seems about correct, from a data attribute structure/organization POV. > > 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) - AFAIR SCSI mode info pages might contain hints as to whether a disk is "rotating" (but possibly these are not fully reliably accessible pre-spinup, and mode info page content probably is unreliable, too) - projects such as smartmontools might be able to provide some hints as to how to reliably detect *certain* non-rotating types (i.e., SSD) - the kernel must already have some mechanisms to discern between (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM command) - if we want to avoid doing spinup handling (I guess we do), then that handling should be implemented *within* the function that is doing that (sd_spinup_disk(), or perhaps an outer wrapper of it, sd_try_spinup_disk()) rather than at one specific callsite of that function only (think sd_spinup_disk() *will* be allowed to "pretend" a "success" result for all storage types which simply do not need spinup) - finally, it might be questionable *why* (whether) at certain points we currently need (decide) to do spinup requests - I guess it's in order to ensure in advance that the disk will be ready once it actually will be needed, or so Thank you very much for having come up with this issue & HTH, Andreas Mohr -- 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/