<?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: v0.46 released</title>
	<atom:link href="http://ceph.com/releases/v0-46-released/feed/" rel="self" type="application/rss+xml" />
	<link>http://ceph.com/releases/v0-46-released/</link>
	<description></description>
	<lastBuildDate>Tue, 14 May 2013 19:48:08 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Vladimir Bashkirstev</title>
		<link>http://ceph.com/releases/v0-46-released/#comment-131</link>
		<dc:creator>Vladimir Bashkirstev</dc:creator>
		<pubDate>Mon, 14 May 2012 13:28:22 +0000</pubDate>
		<guid isPermaLink="false">http://ceph.newdream.net/?p=633#comment-131</guid>
		<description>Would you please elaborate on phrase &quot;Patches for wire it up to qemu are still working their way upstream (and won’t work for virtio until virtio gets discard support).&quot;

I have issue that performance QEMU+RBD is quite low: I ran bonnie++ to measure performance and it shows 52 (FIFTY TWO!) seconds latency and 1.3Mb per second throughtput when writing over existing data. This is way too low! Same RBD mounted by kernel client performs much faster. So I guess issue is somewhere in QEMU+RBD. Hence the qestion: what is expected time for patches to get upstream and if they will get there will it fix my issue?</description>
		<content:encoded><![CDATA[<p>Would you please elaborate on phrase &#8220;Patches for wire it up to qemu are still working their way upstream (and won’t work for virtio until virtio gets discard support).&#8221;</p>
<p>I have issue that performance QEMU+RBD is quite low: I ran bonnie++ to measure performance and it shows 52 (FIFTY TWO!) seconds latency and 1.3Mb per second throughtput when writing over existing data. This is way too low! Same RBD mounted by kernel client performs much faster. So I guess issue is somewhere in QEMU+RBD. Hence the qestion: what is expected time for patches to get upstream and if they will get there will it fix my issue?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
