From: Ric Wheeler <ricwheeler@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Howard Chu <hyc@symas.com>, Theodore Ts'o <tytso@mit.edu>,
Chinmay V S <cvs268@gmail.com>,
Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
matthew@wil.cx
Subject: Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?
Date: Sat, 23 Nov 2013 21:43:16 -0500 [thread overview]
Message-ID: <529167C4.601@gmail.com> (raw)
In-Reply-To: <20131124002236.GA10600@amd.pavel.ucw.cz>
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
next prev parent reply other threads:[~2013-11-24 2:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 12:12 Why is O_DSYNC on linux so slow / what's wrong with my SSD? Stefan Priebe - Profihost AG
2013-11-20 12:54 ` Christoph Hellwig
2013-11-20 13:34 ` Chinmay V S
2013-11-20 13:38 ` Christoph Hellwig
2013-11-20 14:12 ` Stefan Priebe - Profihost AG
2013-11-20 15:22 ` Chinmay V S
2013-11-20 15:37 ` Theodore Ts'o
2013-11-20 15:55 ` J. Bruce Fields
2013-11-20 17:11 ` Chinmay V S
2013-11-20 17:58 ` J. Bruce Fields
2013-11-20 18:43 ` Chinmay V S
2013-11-21 10:11 ` Christoph Hellwig
2013-11-22 20:01 ` Stefan Priebe
2013-11-22 20:37 ` Ric Wheeler
2013-11-22 21:05 ` Stefan Priebe
2013-11-23 18:27 ` Stefan Priebe
2013-11-23 19:35 ` Ric Wheeler
2013-11-23 19:48 ` Stefan Priebe
2013-11-25 7:37 ` Stefan Priebe
2020-01-08 6:58 ` slow sync performance on LSI / Broadcom MegaRaid performance with battery cache Stefan Priebe - Profihost AG
2013-11-22 19:57 ` Why is O_DSYNC on linux so slow / what's wrong with my SSD? Stefan Priebe
2013-11-24 0:10 ` One Thousand Gnomes
2013-11-20 16:02 ` Howard Chu
2013-11-23 20:36 ` Pavel Machek
2013-11-23 23:01 ` Ric Wheeler
2013-11-24 0:22 ` Pavel Machek
2013-11-24 1:03 ` One Thousand Gnomes
2013-11-24 2:43 ` Ric Wheeler [this message]
2013-11-22 19:55 ` Stefan Priebe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529167C4.601@gmail.com \
--to=ricwheeler@gmail.com \
--cc=cvs268@gmail.com \
--cc=hch@infradead.org \
--cc=hyc@symas.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=pavel@ucw.cz \
--cc=s.priebe@profihost.ag \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.