Messages in this thread | | | Date | Sat, 23 Nov 2013 18:01:32 -0500 | From | Ric Wheeler <> | Subject | Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD? |
| |
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... > > Pavel
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.
Ric
| |