From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753518AbdEHJJu (ORCPT ); Mon, 8 May 2017 05:09:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59168 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751828AbdEHJJr (ORCPT ); Mon, 8 May 2017 05:09:47 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8DB899D42C Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hdegoede@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8DB899D42C Subject: Re: Race to power off harming SATA SSDs To: Ricard Wanderlof , David Woodhouse Cc: Pavel Machek , Tejun Heo , boris.brezillon@free-electrons.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, linux-mtd@lists.infradead.org, Henrique de Moraes Holschuh References: <20170410232118.GA4816@khazad-dum.debian.net> <20170410235206.GA28603@wtj.duckdns.org> <20170507204007.GA25628@atrey.karlin.mff.cuni.cz> <1494228094.6528.14.camel@infradead.org> <1494231215.6528.22.camel@infradead.org> <1494233673.6528.28.camel@infradead.org> From: Hans de Goede Message-ID: <7ee84982-cfad-94d7-4e22-4edbeb852b32@redhat.com> Date: Mon, 8 May 2017 11:09:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 08 May 2017 09:09:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 08-05-17 11:06, Ricard Wanderlof wrote: > > On Mon, 8 May 2017, David Woodhouse wrote: > >>> On Mon, 8 May 2017, David Woodhouse wrote: >>>> Our empirical testing trumps your "can never happen" theory :) >>> >>> I'm sure it does. But what is the explanation then? Has anyone analyzed >>> what is going on using an oscilloscope to verify relationship between >>> erase command and supply voltage drop? >> >> Not that I'm aware of. Once we have reached the "it does happen and we >> have to cope" there was not a lot of point in working out *why* it >> happened. >> >> In fact, the only examples I *personally* remember were on NOR flash, >> which takes longer to erase. So it's vaguely possible that it doesn't >> happen on NAND. But really, it's not something we should be depending >> on and the software mechanisms have to remain in place. > > My point is really that say that the problem is in fact not that the erase > is cut short due to the power fail, but that the software issues a second > command before the first erase command has completed, for instance, or > some other situation. Then we'd have a concrete situation which we can > resolve (i.e., fix the bug), rather than assuming that it's the hardware's > fault and implement various software workarounds. You're forgetting that the SSD itself (this thread is about SSDs) also has a major software component which is doing housekeeping all the time, so even if the main CPU gets reset the SSD's controller may still happily be erasing blocks. Regards, Hans