MySQL Forums :: Performance :: A proposal to make disk IO much faster under SSD


Advanced Search

Re: A proposal to make disk IO much faster under SSD
Posted by: Rick James ()
Date: May 31, 2016 09:48PM

The SSD manufacturer previously known as Fusion solved part of the problem. The "doublewrite" buffer in InnoDB prevents corruption that can (very rarely) be caused by "torn pages". Since InnoDB likes to write 16KB at a time, but devices like to work in smaller units, a 16KB page could be partially written during a power failure. The doublewrite solves that by writing the block twice. Fusion IO, instead, guarantees atomic writes for the 16KB pages.

Another manufacturer, Violin, streamlined the data path so that a cache is not needed. It does not return an ACK until the write is completed.Is this what you are looking for?

A RAID controller with Battery-Backed Write Cache also solves the problem for both HDD and SSD. Even with HDD, writes can seem "instantaneous".

Virident (now part of HGST) had a capacitor big enough to allow flushing its cache.

With Galera, you can turn off all the IO protections. Instead, rely on Galera's ability to recover a crashed node at a higher level. (This assumes you don't have all the nodes co-located.)

Back to your proposal. First, this forum is not the right place to propose it. Instead, I recommend you write out a few more details and file a feature request with http://bugs.mysql.com . That is the 'right' place to provide suggestions (as well as bugs and documentation changes).

Options: ReplyQuote


Subject Views Written By Posted
A proposal to make disk IO much faster under SSD 703 suiyemin sui 05/29/2016 09:16PM
Re: A proposal to make disk IO much faster under SSD 432 Rick James 05/31/2016 09:48PM
Re: A proposal to make disk IO much faster under SSD 348 suiyemin sui 06/01/2016 02:05AM
Re: A proposal to make disk IO much faster under SSD 305 Rick James 06/04/2016 04:38PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.