Re: [GSOC] HAMMER2 compression feature week1 report

[Daniel Flores <daniel5555@xxxxxxxxx>]

--089e013d1c4c544dd804e299a21e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 28, 2013 at 9:53 PM, Radio m=C5=82odych bandyt=C3=B3w <
radiomlodychbandytow@o2.pl> wrote:

> On 28/07/2013 21:08, Daniel Flores wrote:
> > we don't reference previous blocks at this moment
> Do you intend to add it? How?
>

At this moment I don't have plans regarding previous blocks, but maybe in
the course of optimizing the write path there will be some ideas about it.
We'll see.


> No, they are not the same, but in a way that doesn't matter here - I set
>  'sector size' to 32 KB, so even if a block compresses to less than 16,
> it takes 32 KB.
> I checked, the tail block compressed from 47875 to 32038.
>

Oh, I understand now why you got that block compressed and I didn't.
It's just that my prototype application, that I used to test this algorithm
and generate my test results, always tries to compress a whole 64KB block.
So, in this case, instead of trying to compress just 47875 bytes of data,
it tried to compress a block that contained that data and also some
garbage, which, logically, didn't lead to a successful compression.


> If you're open to researching other algorithm options, I suggest looking
>  at fsbench, it's going to be easier to adapt it to the way HAMMER2 works
> than to add other algorithms to the kernel:
> http://encode.ru/threads/1371-Filesystem-benchmark?highlight=3Dfsbench
> Note that the latest version crashes on your book2 with settings as
> above, you made me find an integer underflow. Will upload an update
> later today.
>

OK, this looks really interesting. This application can make the process of
testing an algorithm a lot easier.
I'll take a closer look at it soon.

Thank you.


Daniel

--089e013d1c4c544dd804e299a21e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Jul 28, 2013 at 9:53 PM, Radio m=C5=82odych bandyt=
=C3=B3w <span dir=3D"ltr">&lt;<a href=3D"mailto:radiomlodychbandytow@o2.pl"=
 target=3D"_blank">radiomlodychbandytow@o2.pl</a>&gt;</span> wrote:<br><div=
 class=3D"gmail_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 28/07/201=
3 21:08, Daniel Flores wrote:<br>
&gt; we don&#39;t reference previous blocks at this moment<br>
</div>Do you intend to add it? How?<br></blockquote><div><br></div><div>At =
this moment I don&#39;t have plans regarding previous blocks, but maybe in =
the course of optimizing the write path there will be some ideas about it. =
We&#39;ll see.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style=3D"color:r=
gb(34,34,34)">No, they are not the same, but in a way that doesn&#39;t matt=
er here - I set</span><br>

</div>
&#39;sector size&#39; to 32 KB, so even if a block compresses to less than =
16,<br>
it takes 32 KB.<br>
I checked, the tail block compressed from 47875 to 32038.<br></blockquote><=
div><br></div><div>Oh, I understand now why you got that block compressed a=
nd I didn&#39;t.</div><div>It&#39;s just that my prototype application, tha=
t I used to test this algorithm and generate my test results, always tries =
to compress a whole 64KB block. So, in this case, instead of trying to comp=
ress just 47875 bytes of data, it tried to compress a block that contained =
that data and also some garbage, which, logically, didn&#39;t lead to a suc=
cessful compression.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style=3D"color:r=
gb(34,34,34)">If you&#39;re open to researching other algorithm options, I =
suggest looking</span><br>

</div>
at fsbench, it&#39;s going to be easier to adapt it to the way HAMMER2 work=
s<br>
than to add other algorithms to the kernel:<br>
<a href=3D"http://encode.ru/threads/1371-Filesystem-benchmark?highlight=3Df=
sbench" target=3D"_blank">http://encode.ru/threads/1371-Filesystem-benchmar=
k?highlight=3Dfsbench</a><br>
Note that the latest version crashes on your book2 with settings as<br>
above, you made me find an integer underflow. Will upload an update<br>
later today.<br></blockquote><div><br></div><div>OK, this looks really inte=
resting. This application can make the process of testing an algorithm a lo=
t easier.</div><div>I&#39;ll take a closer look at it soon.</div><div>
<br></div><div>Thank you.</div><div><br></div><div><br></div><div>Daniel</d=
iv></div></div></div>

--089e013d1c4c544dd804e299a21e--