You're right about the broken links, my bad.
The first link related to a few statements by Mark Ruijter, copy/pasted below :
> 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% f
The second link is broken, just remove scribe. from it.
https://twitter.com/#!/otisg/status/148848850914902016
It causes a cross-domain error, not sure why he could see it though.
On Wednesday, February 15, 2012 9:23:37 AM, Kok, Auke-jan H wrote:
On Tue, Feb 14, 2012 at 1:47 PM, Hugo Chevrain
On Tue, Feb 14, 2012 at 1:47 PM, Hugo Chevrain wrote:
>>
>> Are you sure about these figures ? the difference seems too large. It's
> almost
>> unbelievable.
>>
>> --
>
> You should not,
> Mark Ruijter found the same for LessFS (http://www.lessfs.com/wordpress/?
> p=688) and there is also such fin
>
> Are you sure about these figures ? the difference seems too large. It's
almost
> unbelievable.
>
> --
You should not,
Mark Ruijter found the same for LessFS (http://www.lessfs.com/wordpress/?
p=688) and there is also such finding into an Hadoop thread
(https://scribe.twitter.com/#!/otisg/
Markus Lindberg writes:
>
>
> Are you sure about these figures ? the difference seems too large. It's almost
> unbelievable.
Yes, my benchmarks totally disagree with them. In my tests lz4 is
generally slower than snappy-c.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubsc
>
> Silesia corpus (avg of 10 runs), AMD bulldozer box, 12G ram, 1Ghz cpu:
>
> lz4 = 739860 us ( 286 MB/s) 195930 us (1081 MB/s) 211957760
-> 101630873 47.9%
> snappy 1.0.4 = 1050 ms ( 201 MB/s) 248 ms ( 853 MB/s) 211957760
-> 104739310 49.4%
> snappy-c = 9
Hi,
so here it is, LZ4 compression method inside btrfs. The patchset is based on
top of current Chris' for-linus + Andi's snappy implementation + the fixes from
Li Zefan. Passes xfstests and stresstests.
I haven't measured performance on wide range of hardware or workloads, rather
wanted to publi
