<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><br>
</p>
<meta content="text/html; charset=UTF-8">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Ah. As it turns out, much more complicated than I anticipated. Thanks for explaining...</p>
<p><br>
</p>
<p></p>
<p style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
I have no expertise in compression algorithms, so that I will have to just watch from the sidelines. Good luck.</p>
<span><br>
When you are further along, I remain interested in helping out with the Lustre side of things.</span>
<p></p>
<p><span><br>
</span></p>
<p><span>One more question - Do you have a plan to make this work *without* the ZFS integration as well, for those using ldiskfs? That seems straightforward enough - compress/decompress at send and recieve time - even if the benefits would be smaller, but
not everyone (Cray, f.x.) is using ZFS, so I'm very interested in something that would help ldiskfs as well. (Which is not to say don't do the deeper integration with ZFS. Just that we'd like something available for ldiskfs too.)</span></p>
<p><span><br>
</span></p>
<p>Regards,</p>
<p><span>- Patrick</span></p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Anna Fuchs <anna.fuchs@informatik.uni-hamburg.de><br>
<b>Sent:</b> Friday, July 28, 2017 4:57:27 AM<br>
<b>To:</b> Patrick Farrell; Xiong, Jinshan<br>
<b>Cc:</b> Matthew Ahrens; Zhuravlev, Alexey; lustre-devel<br>
<b>Subject:</b> Re: [lustre-devel] Design proposal for client-side compression</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Patrick,<br>
<br>
On Thu, 2017-07-27 at 19:22 +0000, Patrick Farrell wrote:<br>
> Ann,<br>
> <br>
> I would be happy to help with review, etc, on this once it's ready to<br>
> be posted.<br>
<br>
thanks for that! <br>
<br>
> In the meantime, I am curious about how you handled the compression<br>
> and the discontiguous set of pages problem. Did you use scatter-<br>
> gather lists like the encryption code does, or some other solution?<br>
<br>
I am mainly working on the infrastructure and Lustre/ZFS integration<br>
regardless the concrete algorithm, but we faced this problem very<br>
early. In my prototype I still have the very costly approach of<br>
allocating three contiguous buffers (src, dst, wrkmem), allocating<br>
additional destination pages, copying original pages to void* src<br>
buffer, compressing to void* dst buffer and again copying to dst page<br>
buffer. A lot of expensive copies and memory wasting. But with the<br>
original Kernel-LZ4 there is no other way. I can send you the<br>
corresponding code part, but it is totally boring - alloc, alloc,<br>
alloc... copy, copy, ... copy.<br>
<br>
In parallel to my work site, we assigned a student to adopt LZ4 to the<br>
page structure. Our first idea has also been scatter-lists seen in the<br>
encryption code. Since scatter-lists use linked lists it somehow turned<br>
out to be very inefficient for traversing the data. The corresponding<br>
Bachelor's thesis will be submitted soon (within a month?), so we have<br>
to proofread it in detail. However, the student implemented another<br>
version of LZ4, which works directly on pages (code party online, full<br>
version will follow).<br>
It is tested, but might be not in the productive stage now (will<br>
hopefully be after submission and reviewing). This version shows a<br>
little lower compression ratio but comparable or better speed. We will<br>
see how we can use it to avoid the memory and copy overhead. It seemed <br>
there is no good way how to change only the data structure in a clean<br>
way without changing the de-/compressor's logic. <br>
<br>
Another interesting thing is the newest LZ4m [0], which is similar to<br>
the work of our student in many aspects, but still differs (waiting for<br>
final thesis). <br>
<br>
However, for the LZ4 we see good chances to get rid of that overhead by<br>
using which ever modification. But since we want and should support<br>
more algorithms, we still do not have any universal solution. E.g. for<br>
zstd, which also seems to be suitable for our needs (another thesis..),<br>
we would need to make same efforts again or pay the overhead. <br>
<br>
[0] <a href="http://csl.skku.edu/papers/icce17.pdf" id="LPlnk849103" previewremoved="true">
http://csl.skku.edu/papers/icce17.pdf</a>
<div id="LPBorder_GT_15012495922380.7322662546188166" style="margin-bottom: 20px; overflow: auto; width: 100%; text-indent: 0px;">
<table id="LPContainer_15012495922290.322554155531259" role="presentation" cellspacing="0" style="width: 90%; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);">
<tbody>
<tr valign="top" style="border-spacing: 0px;">
<td id="TextCell_15012495922350.06322438077996928" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;">
<div id="LPRemovePreviewContainer_15012495922350.5292562527720688"></div>
<div id="LPTitle_15012495922350.36519958265615626" style="top: 0px; color: rgb(0, 114, 198); font-weight: normal; font-size: 21px; font-family: wf_segoe-ui_light, "Segoe UI Light", "Segoe WP Light", "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; line-height: 21px;">
<a id="LPUrlAnchor_15012495922360.49010463562942963" href="http://csl.skku.edu/papers/icce17.pdf" target="_blank" style="text-decoration: none;">LZ4m: A Fast Compression Algorithm for In-Memory Data</a></div>
<div id="LPMetadata_15012495922370.9582151236350396" style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: normal; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; font-size: 14px; line-height: 14px;">
csl.skku.edu</div>
<div id="LPDescription_15012495922370.2568590884277644" style="display: block; color: rgb(102, 102, 102); font-weight: normal; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;">
LZ4m: A Fast Compression Algorithm for In-Memory Data Se-Jun Kwon ∗, Sang-Hoon Kim†, Hyeong-Jun Kim∗, and Jin-Soo Kim ∗College of Information and ...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
<br>
If anyone has other ideas, please, let me know!<br>
<br>
Regards,<br>
Anna<br>
</div>
</span></font></div>
</body>
</html>