From: Simon Arlott <simon@octiron.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Jonathan Corbet <corbet@lwn.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-scsi@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot
Date: Thu, 18 Jun 2020 13:25:18 +0100 [thread overview]
Message-ID: <9877e7de-d573-694b-2b75-95192756684b@0882a8b5-c6c3-11e9-b005-00805fc181fe> (raw)
In-Reply-To: <20200618072138.GA11778@infradead.org>
On 18/06/2020 08:21, Christoph Hellwig wrote:
> On Wed, Jun 17, 2020 at 07:49:57PM +0100, Simon Arlott wrote:
>> Avoiding a stop of the disk on a reboot is appropriate for HDDs because
>> they're likely to continue to be powered (and should not be told to spin
>> down only to spin up again) but the default behaviour for SSDs should
>> be changed to stop them before the reboot.
>
> I don't think that is true in general. At least for most current server
> class and older desktop and laptop class systems they use the same
> format factors and enclosures, although they are slightly divering now.
>
> So I think this needs to be quirked based on the platform and/or
> enclosure.
Are you referring to the behaviour for handling HDDs or SSDs?
For HDDs, the default "1" option could mean "automatic" and apply to
rotational disks when power loss is expected.
For SSDs, I don't think an extra stop should ever be an issue.
--
Simon Arlott
next prev parent reply other threads:[~2020-06-18 12:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 18:49 [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot Simon Arlott
2020-06-17 19:19 ` Bart Van Assche
2020-06-17 19:32 ` Simon Arlott
2020-06-18 7:21 ` Christoph Hellwig
2020-06-18 12:25 ` Simon Arlott [this message]
2020-06-18 13:49 ` Christoph Hellwig
2020-07-05 21:31 ` Henrique de Moraes Holschuh
2020-07-07 10:18 ` Christoph Hellwig
2020-06-18 8:36 ` Damien Le Moal
2020-06-18 12:25 ` Simon Arlott
2020-06-18 23:31 ` Damien Le Moal
2020-06-28 18:23 ` Simon Arlott
2020-06-30 1:05 ` Damien Le Moal
2020-06-23 13:36 ` Pavel Machek
2020-06-28 18:22 ` Simon Arlott
2020-06-23 20:42 ` Henrique de Moraes Holschuh
2020-06-28 18:31 ` Simon Arlott
2020-06-28 19:42 ` Henrique de Moraes Holschuh
2020-06-30 3:31 ` Ming Lei
2020-07-02 21:16 ` Pavel Machek
2020-07-03 14:13 ` David Laight
2020-07-04 11:49 ` Pavel Machek
2020-07-05 22:19 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9877e7de-d573-694b-2b75-95192756684b@0882a8b5-c6c3-11e9-b005-00805fc181fe \
--to=simon@octiron.net \
--cc=corbet@lwn.net \
--cc=hch@infradead.org \
--cc=jejb@linux.ibm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).