DragonFly BSD
DragonFly kernel List (threaded) for 2013-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [GSOC] HAMMER2 compression feature week6 report


From: Daniel Flores <daniel5555@xxxxxxxxx>
Date: Tue, 30 Jul 2013 03:43:58 +0200

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

Thank you for feedback.

On Mon, Jul 29, 2013 at 7:47 PM, Radio m=C5=82odych bandyt=C3=B3w <
radiomlodychbandytow@o2.pl> wrote:

> Also, it would be nice to see performance in small files. Not
> multimegabyte giants, but mere sub-1-blockers, down to sub-1-sectors.
>

OK, I'll do a couple of tests on small files (both single file and group
tests) and publish them soon. Maybe in this week's report, but I'll try to
do it sooner, if possible...


> BTW it just occurred to me the kernel code needlessly tries to compress
> files that take just 1 sector. And why is there no support for 512B
> blocks? It's a HAMMER2 limitation, right?


As far as I understand, the current standard for sector size is 4KB, but
still there are plenty of drives which sector size is 512B, so it probably
makes sense to try to compress files which size is between 512B and 4KB.
When the file size is less or equal to 512B, it is directly embedded into
an inode and it's not compressed in that case.

As about 512B blocks, we currently have 1KB block as a minimum sized block,
but it's not limited to 1KB in theory.


Daniel

--001a1133f7262245f904e2b0be1a
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thank you for feedback.</div><div><br></div>On Mon, J=
ul 29, 2013 at 7:47 PM, Radio m=B3odych bandyt=F3w <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:radiomlodychbandytow@o2.pl"; target=3D"_blank">radiomlodychb=
andytow@o2.pl</a>&gt;</span> wrote:<br>


<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">Also, it would be nice to see performance in small files. Not<br>
multimegabyte giants, but mere sub-1-blockers, down to sub-1-sectors.<br></=
blockquote><div><br></div><div>OK, I&#39;ll do a couple of tests on small f=
iles (both single file and group tests) and publish them soon. Maybe in thi=
s week&#39;s report, but I&#39;ll try to do it sooner, if possible...</div>


<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">BTW it just occurred to me the=
 kernel code needlessly tries to compress<br>
files that take just 1 sector. And why is there no support for 512B<br>
blocks? It&#39;s a HAMMER2 limitation, right?</blockquote><div><br></div><d=
iv>As far as I understand, the current standard for sector size is 4KB, but=
 still there are plenty of drives which sector size is 512B, so it probably=
 makes sense to try to compress files which size is between 512B and 4KB. W=
hen the file size is less or equal to 512B, it is directly embedded into an=
 inode and it&#39;s not compressed in that case.</div>

<div><br></div><div>As about 512B blocks, we currently have 1KB block as a =
minimum sized block, but it&#39;s not limited to 1KB in theory.</div>
<div><br></div><div><br></div><div>Daniel</div></div></div></div>

--001a1133f7262245f904e2b0be1a--



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]