<?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: Lessfs-1.6.0-beta0 has been released.</title>
	<atom:link href="http://www.lessfs.com/wordpress/?feed=rss2&#038;p=684" rel="self" type="application/rss+xml" />
	<link>http://www.lessfs.com/wordpress/?p=684</link>
	<description>Open source data de-duplication &#38; data tiering for less</description>
	<lastBuildDate>Wed, 18 Mar 2015 13:40:57 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.0.7</generator>
	<item>
		<title>By: gwpl</title>
		<link>http://www.lessfs.com/wordpress/?p=684&#038;cpage=1#comment-3483</link>
		<dc:creator><![CDATA[gwpl]]></dc:creator>
		<pubDate>Fri, 23 Mar 2012 22:19:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessfs.com/wordpress/?p=684#comment-3483</guid>
		<description><![CDATA[“By default Lessfs will now compile with berkeleydb instead of tokyocabinet.” – Could you be more specific, what were the reasons for such decision? (Or link to related materials, like mailinglist discussions?)

Currently there is successor of &lt;a href=&quot;//fallabs.com/tokyocabinet/”&quot; rel=&quot;nofollow&quot;&gt;Tokyo Cabinet&lt;/a&gt; , which is &lt;a href=&quot;http://fallabs.com/kyotocabinet/&quot; rel=&quot;nofollow&quot;&gt;Kyoto Cabinet&lt;/a&gt;. Have you considered it ?

What are practical implication of switching LessFS from Tokyo Cabinet to berkeleydb ? I am most curious about performance. :)

Thanks in advance for all info and pointing to right places. I’d love to read more about details related under the cover of this stuff.

Best,
Grzegorz]]></description>
		<content:encoded><![CDATA[<p>“By default Lessfs will now compile with berkeleydb instead of tokyocabinet.” – Could you be more specific, what were the reasons for such decision? (Or link to related materials, like mailinglist discussions?)</p>
<p>Currently there is successor of <a href="//fallabs.com/tokyocabinet/”" rel="nofollow">Tokyo Cabinet</a> , which is <a href="http://fallabs.com/kyotocabinet/" rel="nofollow">Kyoto Cabinet</a>. Have you considered it ?</p>
<p>What are practical implication of switching LessFS from Tokyo Cabinet to berkeleydb ? I am most curious about performance. <img src="http://www.lessfs.com/wordpress/wp-includes/images/smilies/icon_smile.gif" alt=":)" class="wp-smiley" /></p>
<p>Thanks in advance for all info and pointing to right places. I’d love to read more about details related under the cover of this stuff.</p>
<p>Best,<br />
Grzegorz</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bsd</title>
		<link>http://www.lessfs.com/wordpress/?p=684&#038;cpage=1#comment-3116</link>
		<dc:creator><![CDATA[bsd]]></dc:creator>
		<pubDate>Thu, 19 Jan 2012 20:20:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessfs.com/wordpress/?p=684#comment-3116</guid>
		<description><![CDATA[Great ! Sounds promising...]]></description>
		<content:encoded><![CDATA[<p>Great ! Sounds promising&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Ruijter</title>
		<link>http://www.lessfs.com/wordpress/?p=684&#038;cpage=1#comment-3114</link>
		<dc:creator><![CDATA[Mark Ruijter]]></dc:creator>
		<pubDate>Wed, 18 Jan 2012 07:56:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessfs.com/wordpress/?p=684#comment-3114</guid>
		<description><![CDATA[Thanks for making me aware that there even is something like LZ4.
I just looked into it and it appears to be promising. On average the speeds appear to be 48% faster then snappy.
This is amazing since snappy has proved to be 30% faster then QuickLZ which once was the fastest compression protocol.

http://fastcompression.blogspot.com/
https://issues.apache.org/jira/browse/HADOOP-7657?focusedCommentId=13170733&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13170733

Porting a new compression algorithm to Lessfs is very simple.
So when I have time I&#039;ll give it a go so we can see if LZ4 lives up to it&#039;s promise.

Thanks,

Mark.]]></description>
		<content:encoded><![CDATA[<p>Thanks for making me aware that there even is something like LZ4.<br />
I just looked into it and it appears to be promising. On average the speeds appear to be 48% faster then snappy.<br />
This is amazing since snappy has proved to be 30% faster then QuickLZ which once was the fastest compression protocol.</p>
<p><a href="http://fastcompression.blogspot.com/" rel="nofollow">http://fastcompression.blogspot.com/</a><br />
<a href="https://issues.apache.org/jira/browse/HADOOP-7657?focusedCommentId=13170733&#038;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13170733" rel="nofollow">https://issues.apache.org/jira/browse/HADOOP-7657?focusedCommentId=13170733&#038;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13170733</a></p>
<p>Porting a new compression algorithm to Lessfs is very simple.<br />
So when I have time I&#8217;ll give it a go so we can see if LZ4 lives up to it&#8217;s promise.</p>
<p>Thanks,</p>
<p>Mark.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bsd</title>
		<link>http://www.lessfs.com/wordpress/?p=684&#038;cpage=1#comment-3113</link>
		<dc:creator><![CDATA[bsd]]></dc:creator>
		<pubDate>Tue, 17 Jan 2012 21:52:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessfs.com/wordpress/?p=684#comment-3113</guid>
		<description><![CDATA[Have you had time to test LZ4 and compare it to Snappy ?]]></description>
		<content:encoded><![CDATA[<p>Have you had time to test LZ4 and compare it to Snappy ?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
