<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: On Benchmarks on SSD</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2010/07/14/on-benchmarks-on-ssd/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2010/07/14/on-benchmarks-on-ssd/</link>
	<description>Percona&#039;s MySQL &#38; InnoDB performance and scalability blog</description>
	<lastBuildDate>Sat, 11 Feb 2012 16:45:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Shirish Jamthe</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/14/on-benchmarks-on-ssd/comment-page-1/#comment-770788</link>
		<dc:creator>Shirish Jamthe</dc:creator>
		<pubDate>Fri, 06 Aug 2010 02:15:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3353#comment-770788</guid>
		<description>Patrick,

Be careful of the loopback device. In our testing it shows that it lies about fsync, so the process that calls fsync on loopback device file may think data is persistent but that is not usually the case.</description>
		<content:encoded><![CDATA[<p>Patrick,</p>
<p>Be careful of the loopback device. In our testing it shows that it lies about fsync, so the process that calls fsync on loopback device file may think data is persistent but that is not usually the case.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/14/on-benchmarks-on-ssd/comment-page-1/#comment-769460</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Fri, 16 Jul 2010 16:40:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3353#comment-769460</guid>
		<description>Patrick,

I would be careful with approaches like this.  You do not really know what other support from OS and filesystem for SSD devices may be disabled... plus  With reads/writes sometimes at 1GB/sec rate the overhead on CPU/Memory bus from extra copying may not be trivial.

I think it is practical to run benchmarks as close to production setups as possible for them to have highest relevance</description>
		<content:encoded><![CDATA[<p>Patrick,</p>
<p>I would be careful with approaches like this.  You do not really know what other support from OS and filesystem for SSD devices may be disabled&#8230; plus  With reads/writes sometimes at 1GB/sec rate the overhead on CPU/Memory bus from extra copying may not be trivial.</p>
<p>I think it is practical to run benchmarks as close to production setups as possible for them to have highest relevance</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Domack</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/14/on-benchmarks-on-ssd/comment-page-1/#comment-769386</link>
		<dc:creator>Patrick Domack</dc:creator>
		<pubDate>Thu, 15 Jul 2010 13:20:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3353#comment-769386</guid>
		<description>Wouldn&#039;t mounting the device via the loopback device hide the fact it&#039;s an ssd from the os, making the trim command not work. Then your one step closer to better results, at the expense of some more cpu overhead.</description>
		<content:encoded><![CDATA[<p>Wouldn&#8217;t mounting the device via the loopback device hide the fact it&#8217;s an ssd from the os, making the trim command not work. Then your one step closer to better results, at the expense of some more cpu overhead.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

