linux-kernel - Re: Stop SSD from waiting for "Spinning up disk..."

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jun 2015 20:26:12 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Jeff Chua <jeff.chua.linux@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: Stop SSD from waiting for "Spinning up disk..."

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
> <gregkh@...xxxxxxxxxxxxxxxx> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/