Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux