<div dir="ltr"><div>Thank you for feedback.</div><div><br></div>On Mon, Jul 29, 2013 at 7:47 PM, Radio m³odych bandytów <span dir="ltr"><<a href="mailto:radiomlodychbandytow@o2.pl" target="_blank">radiomlodychbandytow@o2.pl</a>></span> wrote:<br>


<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="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'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...</div>


<div> </div><blockquote class="gmail_quote" style="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's a HAMMER2 limitation, right?</blockquote><div><br></div><div>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.</div>

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