From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756429Ab3KXCnU (ORCPT ); Sat, 23 Nov 2013 21:43:20 -0500 Received: from mail-qa0-f45.google.com ([209.85.216.45]:49266 "EHLO mail-qa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752781Ab3KXCnS (ORCPT ); Sat, 23 Nov 2013 21:43:18 -0500 Message-ID: <529167C4.601@gmail.com> Date: Sat, 23 Nov 2013 21:43:16 -0500 From: Ric Wheeler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Pavel Machek CC: Howard Chu , "Theodore Ts'o" , Chinmay V S , Stefan Priebe - Profihost AG , Christoph Hellwig , linux-fsdevel@vger.kernel.org, Al Viro , LKML , matthew@wil.cx Subject: Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD? References: <528CA73B.9070604@profihost.ag> <20131120125446.GA6284@infradead.org> <528CC36A.7080003@profihost.ag> <20131120153703.GA23160@thunk.org> <528CDD19.5060002@symas.com> <20131123203600.GA791@amd.pavel.ucw.cz> <529133CC.4070904@gmail.com> <20131124002236.GA10600@amd.pavel.ucw.cz> In-Reply-To: <20131124002236.GA10600@amd.pavel.ucw.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/23/2013 07:22 PM, Pavel Machek wrote: > On Sat 2013-11-23 18:01:32, Ric Wheeler wrote: >> On 11/23/2013 03:36 PM, Pavel Machek wrote: >>> On Wed 2013-11-20 08:02:33, Howard Chu wrote: >>>> Theodore Ts'o wrote: >>>>> Historically, Intel has been really good about avoiding this, but >>>>> since they've moved to using 3rd party flash controllers, I now advise >>>>> everyone who plans to use any flash storage, regardless of the >>>>> manufacturer, to do their own explicit power fail testing (hitting the >>>>> reset button is not good enough, you need to kick the power plug out >>>>> of the wall, or better yet, use a network controlled power switch you >>>>> so you can repeat the power fail test dozens or hundreds of times for >>>>> your qualification run) before being using flash storage in a mission >>>>> critical situation where you care about data integrity after a power >>>>> fail event. >>>> Speaking of which, what would you use to automate this sort of test? >>>> I'm thinking an SSD connected by eSATA, with an external power >>>> supply, and the host running inside a VM. Drop power to the drive at >>>> the same time as doing a kill -9 on the VM, then you can resume the >>>> VM pretty quickly instead of waiting for a full reboot sequence. >>> I was just pulling power on sata drive. >>> >>> It uncovered "interesting" stuff. I plugged power back, and kernel >>> re-estabilished communication with that drive, but any settings with >>> hdparm were forgotten. I'd say there's some room for improvement >>> there... >> Hi Pavel, >> >> When you drop power, your drive normally loses temporary settings >> (like a change to write cache, etc). >> >> Depending on the class of the device, there are ways to make that >> permanent (look at hdparm or sdparm for details). >> >> This is a feature of the drive and its firmware, not something we >> reset in the device each time it re-appears. > Yes, and I'm arguing that is a bug (as in, < 0.01% people are using > hdparm correctly). Almost no end users use hdparm. Those who do should read the man page and add the -K flag :) Or system scripts that tweak should invoke it with the right flags..... Ric > So you used hparm to disable write cache so that ext3 can be safely > used on your hdd. Now you have glitch on power. Then, system continues > to operate in dangerous mode until reboot. > > I guess it would be safer not to reattach drives after power > fail... (also I wonder what this does to data integrity. Drive lost > content of its writeback cache, but kernel continues... Journal will > not prevent data corruption in this case). > > Pavel