Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752527AbdDKCCl (ORCPT ); Mon, 10 Apr 2017 22:02:41 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:36945 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbdDKCCj (ORCPT ); Mon, 10 Apr 2017 22:02:39 -0400 X-ME-Sender: X-Sasl-enc: Rp5yuKc7vR960r1r3IG60OuDmUfjYq/jEPujCYSSnmvF 1491876157 Date: Mon, 10 Apr 2017 23:02:35 -0300 From: Henrique de Moraes Holschuh To: James Bottomley Cc: Tejun Heo , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org, Hans de Goede Subject: Re: Race to power off harming SATA SSDs Message-ID: <20170411020235.GD10185@khazad-dum.debian.net> References: <20170410232118.GA4816@khazad-dum.debian.net> <20170410235206.GA28603@wtj.duckdns.org> <1491868675.2473.22.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1491868675.2473.22.camel@HansenPartnership.com> X-GPG-Fingerprint1: 4096R/0x0BD9E81139CB4807: C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 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: 1349 Lines: 32 On Mon, 10 Apr 2017, James Bottomley wrote: > On Tue, 2017-04-11 at 08:52 +0900, Tejun Heo wrote: > [...] > > > Any comments? Any clues on how to make the delay "smarter" to > > > trigger only once during platform shutdown, but still trigger per > > > -device when doing per-device hotswapping ? > > > > So, if this is actually an issue, sure, we can try to work around; > > however, can we first confirm that this has any other consequences > > than a SMART counter being bumped up? I'm not sure how meaningful > > that is in itself. > > Seconded; especially as the proposed patch is way too invasive: we run It is a proof of concept thing. It even says so in the patch commit log, and in the cover text. I don't want an one second delay per device. I never proposed that, either. In fact, I *specifically* asked for something else in the paragraph you quoted. I would much prefer an one- or two-seconds delay per platform *power off*. And that's for platforms that do ACPI-like heavy-duty S3/S4/S5 like x86/x86-64. Opportunistic high-frequency suspend on mobile likely requires no such handling. The per-device delay would be needed only for hotplug removal (device delete), and that's just because some hardware powers down bays (like older thinkpads with ATA-compatible bays, and some industrial systems). -- Henrique Holschuh