From owner-svn-src-all@freebsd.org Fri Oct 27 14:50:16 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59367E473B1; Fri, 27 Oct 2017 14:50:16 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0BEC68299; Fri, 27 Oct 2017 14:50:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id l23so7682892lfk.10; Fri, 27 Oct 2017 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bHiVKdqgQm4PbM7sdQHATZcB2twobmmcrNtnylkXGM8=; b=ULSU6LpGu0zoaMdrOVO3P4lvZ3PW6O8Ig+tueG85eDxTJflP03+X2x/FdUZtGpYu/P bKjxAur9eEDCgZwwCQfhFbRpSrdQ2gKbNnuUO20r2rx3IZkUQS7ZBaqaSO6V4RhkXwAG cRLG84NxHwL5bjtP2iznBEPqzUUVNebVfdFRjFnwXaQorftZMwX9n/gvrPV0vZ+NeEcY UdCFnng2q4M3NfGPsuqxnQjjUV3bVwaJ7qdHwtZ9FLPap9AgE+gR/3tu6oalvR74B+2I m/Rwd2CkLMRXCUCikJ2DpMNu+M1TuhTa85OVRpi+Xy50dSMtDq8AKWlEgx9o0KNacQXY UI7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bHiVKdqgQm4PbM7sdQHATZcB2twobmmcrNtnylkXGM8=; b=f/y61hgc3YDPerE7LTmyl3dFQQyQB0R5RitoR+emadCa2nwG2uYkcIGnoJ5o4KVAQQ R2W0qOSQt8m+CPi7SAuPVqd255xsOal56dNWnuouYmFzBdhgwLcFdKZv0pcUyOiwx3hp cTsAOxhRfZ1A8toOORBkSLMlCYDY3lZ9VK0dQxzs6t7aoZWKy0EUS3R1nqvijBAqOqVJ HO0QXixm7g6VyCT0ohgWrDUZeEbouy7D8cmarKoS0gR29BimSEYx+8I29xRJkQcf8vUH u0+SlYP/bS5N5sePu140eE70vqK1mFCMQGdT95h25lL474I28mz28g/6bYndRqmB2c1O 3FSQ== X-Gm-Message-State: AMCzsaVv8jZftRctygtaDACUbqWcWSdV/b8aAVehCG2LzWh1t2GStrIS TbiSABOeCP4VZmKBYKTYpcr3u5Jq62OH3Tk0VWQ= X-Google-Smtp-Source: ABhQp+TIPB8IgPK+K+TrrtNuyuaguQiNnUImooBU9kYJsDcVIVrk7kJnl1j3kss/ZsmSYv4qIixQ2m/LfugjYon/Vyc= X-Received: by 10.25.216.88 with SMTP id p85mr290310lfg.21.1509115813514; Fri, 27 Oct 2017 07:50:13 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.93.24 with HTTP; Fri, 27 Oct 2017 07:50:12 -0700 (PDT) In-Reply-To: References: <201710262253.v9QMrovZ009495@repo.freebsd.org> From: Alan Somers Date: Fri, 27 Oct 2017 08:50:12 -0600 X-Google-Sender-Auth: AExPZdPB9sEiWjsd1Pjlpraj0yw Message-ID: Subject: Re: svn commit: r325026 - head/sys/cam/ata To: Warner Losh Cc: Warner Losh , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 14:50:16 -0000 On Thu, Oct 26, 2017 at 8:27 PM, Warner Losh wrote: > > > On Thu, Oct 26, 2017 at 5:35 PM, Warner Losh wrote: >> >> >> >> On Thu, Oct 26, 2017 at 5:04 PM, Alan Somers wrote: >>> >>> On Thu, Oct 26, 2017 at 4:53 PM, Warner Losh wrote: >>> > Author: imp >>> > Date: Thu Oct 26 22:53:49 2017 >>> > New Revision: 325026 >>> > URL: https://svnweb.freebsd.org/changeset/base/325026 >>> > >>> > Log: >>> > Always send STANDBY IMMEDIATE when shutting down >>> > >>> > To save SMART data and for a drive to understand that it's been >>> > nicely >>> > shutdown, we need to send a STANDBY IMMEDIATE. Modify adaspindown to >>> > use a local CCB on the stack. When we're panicing, used >>> > xpt_polled_action rather than cam_periph_runccb so that we can SEND >>> > IMMEDIATE after we've shutdown the scheduler. >>> > >>> > Sponsored by: Netflix >>> > Reviewed by: scottl@, gallatin@ >>> > Differential Revision: https://reviews.freebsd.org/D12799 >>> > >>> > Modified: >>> > head/sys/cam/ata/ata_da.c >>> >>> Will this put the drive into a standby state just prior to a warm >>> reboot? That could cause lengthy delays on the new boot while the >>> drives spin up. That behavior caused a problem when the mpr driver >>> did it to a JBOD full of 96 SATA drives. On the new boot, each drive >>> spun up one at a time while they were being probed. Eventually the >>> system paniced because run_interrupt_driven_hooks timed out. With >>> mpr, I was able to fix the problem by setting hw.mpr.enable_ssu=0. >> >> >> That's a good question. The standard is silent about what, exactly, the >> Standby state means. We already allow this to be disabled, and this commit >> doesn't change that. It looks like IDLE IMMEDIATE also forces SMART media >> non volatile to be flushed out. >> >> What do you suggest? > > > I see two paths forward. We need to flush the NV SMART data at reboot time. > SSDs that we use, at least, consider it an unclean shutdown if you don't > Idle the drive on reboot because part of that process does a > COMINIT/COMRESET and if the drive is in the Active state, it ticks up the > counter (and with at least one vendor can lose NV SMART data). > > So, path forward #1 is that we do STANDBY IMMEDIATE for SSDs in the > RB_REBOOT case or all drives in the other cases. For HDD and RB_REBOOT we do > only a IDLE IMMEDIATE which shouldn't spin the drives down. This seems to > bake in what we know about storage devices and is easiest for the user. If > we get it right, it's easier for the user. If we get it wrong, the user can > disable all spin downs. > > Path forward #2 is to just make what we send a sysctl. This is unsatisfying > and error-prone, but gives the most flexibility. I don't like this. > > I'd be curious if there's another viable path forward I'm not seeing that > you might know. > > FWIW, we don't connect HDDs to our AHCI ports (they are all on MPT/MPS/MPR > HBAs), so we've not seen any issues in the 6 or so months we've had this in > the tree. > > Warner Is there some reason not to send IDLE IMMEDIATE to both SSDs and HDDs?