Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2210132ybt; Sun, 28 Jun 2020 11:33:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMaRQywOoZGUNl+uVuW4/OL1lAUfKYjwhSBfVUEf0zWx35IiM5UZFJYa4+OMOVnDkj0EDy X-Received: by 2002:a17:906:a0f:: with SMTP id w15mr11467886ejf.332.1593369182751; Sun, 28 Jun 2020 11:33:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593369182; cv=none; d=google.com; s=arc-20160816; b=DdohfvB/rbELzO6rd+4g+Ax4uPmeNv0LCSZfIiDTtnCixxFfJ1dtQ+P92uhQFjfJhK ZpoOsnK0BEGy18Gn6x5hiVWdk7/ieLIY+JJq2hDCEYelSG3Ds7Kqs/uaRw6dcQxmIdxp Z9N/EkGjtHfNM49IL54hOtujUyzPhoVVJFSDK+YEmVpagW+HnoI0h5HCT6+0nTLicZp3 ZfGA6GigRIX8qcFsXCfu40u4YBNWkSiOODaoUKhMV0v8shxUd5vUQhZS8hy8fjGYfl0M hliwSlHYPNOXvLgAfBIa/7RPiwjhDrRWuWABuOfBS1uugGsG3BsJCMCf8es4Ii8VXf94 uW2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :dkim-signature; bh=EmGRDwzXYyrRKHmxgqMp+SlhJvcVmdcX/2jLPUH2gdY=; b=bWUlNwhPUVOgQu8ev+iTu70aDDIezZOfbDTIjWtItMYYtfdyTWzEobHEI4RS4XyjEh l24xQ66aGVFqbgt+G4q6XxnBsN0bnnzM60+9VXlrYH8f6xRFqS9MAUYwVss1A+BJTP+p I44OWFjEuT1bUfhYctihakjJPWU7pcb2omt3NegAFcC5+1d8pcrN4UY1dlsq3gVuNq3i PmTYgNW35TgANrnI0+s/YnMRC0O2BVaUo04JidaRbc1krOVJfCNtpK9i8cVPb6sCpXGq XRwiDIEZqdKpM5uUY6sHE2mP5vyQk9fPMBwMp9sjQza2s4W/VHfqQEFDH8k1c+LKfggb 7/4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@octiron.net header.s=20180214 header.b="dN0e/O1J"; dkim=pass header.i=@octiron.net header.s=20180214 header.b=yVEUycbW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=octiron.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j17si23156ejg.88.2020.06.28.11.32.39; Sun, 28 Jun 2020 11:33:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@octiron.net header.s=20180214 header.b="dN0e/O1J"; dkim=pass header.i=@octiron.net header.s=20180214 header.b=yVEUycbW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=octiron.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726654AbgF1ScS (ORCPT + 99 others); Sun, 28 Jun 2020 14:32:18 -0400 Received: from fourecks.uuid.uk ([147.135.211.183]:53084 "EHLO fourecks.uuid.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726060AbgF1ScS (ORCPT ); Sun, 28 Jun 2020 14:32:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=octiron.net ; s=20180214; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=EmGRDwzXYyrRKHmxgqMp+SlhJvcVmdcX/2jLPUH2gdY=; b=dN0e/O1JdmXcxE4WpKcOasWOJ2 bDhlDt85+BnvqFTDmM4XXu95ME3M/vX+NV7KgVW4xzyuB07zjruAwfCkoPeVAfE/tqLiGCbW84JU2 3lrYqdAPq8uJwkGdoCZXZuN4qqZrXVZSTNBWh9M6mWmFCuE4PKgHAM7QSG/OzqnotWKrLl0VKZnmR 1Q4QgbRF9TFsJaAF8+OWHPLz7NcckYuduT1wECdqX4GgMKB1YbCsjvIQV9Sv3yeqjsNmKc+v6s7va xbp1C6SMZIS1rBjT347tNggTAPJwsm0VEzvm5Ispwjh8Oq9XHRpMR+uytM4+86xt2Vs+giuRfbhXi b1G8mZSw==; Received: by fourecks.uuid.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jpc5y-000652-9A; Sun, 28 Jun 2020 19:32:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=octiron.net ; s=20180214; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=EmGRDwzXYyrRKHmxgqMp+SlhJvcVmdcX/2jLPUH2gdY=; b=yVEUycbW2baGmmDxnxjl/9efBf UPCzJ4AL7NuLlANH6UuUqf2X1120C6if2ejKqe3JhHg94TQWllRebyywcJoegNs/+ZDiXPxsXhkWU aC3Lkhmu6xxfCIPj6JIH+vJpooQjIimbhwdSwF+7UyXUzxrtp4sGafXi4zoGBUj8hPRBuJo3UDPhJ iE+waX/kU4PjDUnJQ80LazUOUewxLFiZErcFHlblFRAhWxqVwDXnaW1/Y6SYMQfe1+MJdzzLvDzhv jZku+jd/GUIEDOIZNCTcAjK6QCzHnUibxwmI7WD7NsNIPVjQvNqy60b5DD4dx8VdSJl25IzlM/c6i bkVaRNcA==; Received: by tsort.uuid.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jpc5t-0007O6-Ot; Sun, 28 Jun 2020 19:31:58 +0100 Subject: Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot To: Henrique de Moraes Holschuh , Damien Le Moal Cc: "James E.J. Bottomley" , "Martin K. Petersen" , Jonathan Corbet , Linux Kernel Mailing List , "linux-scsi@vger.kernel.org" , "linux-doc@vger.kernel.org" References: <499138c8-b6d5-ef4a-2780-4f750ed337d3@0882a8b5-c6c3-11e9-b005-00805fc181fe> <20200623204234.GA16156@khazad-dum.debian.net> From: Simon Arlott Message-ID: <4e9c7e62-b1e4-80b0-8e22-9d57d3431f37@0882a8b5-c6c3-11e9-b005-00805fc181fe> Date: Sun, 28 Jun 2020 19:31:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200623204234.GA16156@khazad-dum.debian.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/06/2020 21:42, Henrique de Moraes Holschuh wrote: > [1] I have long lost the will and energy to pursue this, so *this* is a > throw-away anecdote for anyone that cares: I reported here a few years > ago that many models of *SATA* based SSDs from Crucial/Micron, Samsung > and Intel were complaining (through their SMART attributes) that Linux > was causing unsafe shutdowns. > > https://lkml.org/lkml/2017/4/10/1181 > > TL;DR: wait one *extra* second after the SSD acknowleged the STOP > command as complete before you trust the SSD device is safe to be > powered down (i.e. before reboot, suspend, poweroff/shutdown, and device > removal/detach). This worked around the issue for every vendor and > model of SSD we tested. Looking through that thread, it looks like a simple 1 second delay on shutdown/reboot patch hasn't been proposed yet? In my case none of the SSDs are recording unexpected power loss if they are stopped before the reboot, but the reboot won't necessarily be instantaneous after the last stop command returns. -- Simon Arlott