<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 8:46 PM, Niels de Vos <span dir="ltr">&lt;<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Tue, Jun 27, 2017 at 08:09:25AM -0400, Kaleb S. KEITHLEY wrote:<br>
&gt;<br>
&gt; xxhash doesn&#39;t seem to change much. Last update to the non-test code was six<br>
&gt; months ago.<br>
&gt;<br>
&gt; bundling giant (for some definition of giant) packages/projects would be<br>
&gt; bad. bundling two (three if you count the test) C files doesn&#39;t seem too bad<br>
&gt; when you consider that there are already three or four packages in fedora<br>
&gt; (perl, python, R-digest, ghc (gnu haskell) that have implementations of<br>
&gt; xxhash or murmur but didn&#39;t bother to package a C implementation and use it.<br>
<br>
</span>I prefer to have as little maintenance components in the Gluster sources<br>
as we can. The maintenance burdon is already very high. The number of<br>
changes to xxhash seem limited, but we still need someone to track and<br>
pay attention to them.<br></blockquote><div><br></div><div>I agree that someone should maintain it, and we should add it to MAINTAINERS file <br>(or some other place, where we are tracking the dependencies).<br></div><div><br></div><div>For now, Kotresh will be looking into keeping these changes up-to-date with<br>upstream xxhash project, along with me.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
&gt; I&#39;d be for packaging it in Fedora rather than bundling it in gluster. But<br>
&gt; then we get to &quot;carry&quot; it in rhgs as we do with userspace-rcu.<br>
<br>
</span>We should descide what the most maintainable solution is. Having package<br>
maintainers with the explicit task to keep xxhash updated and current is<br>
apealing to me. Merging (even small) projects into the Gluster codebase<br>
will add more maintenance need to the project members. Therefor I have a<br>
strong preference to use xxhash (or an other library) that is provided<br>
by distributions. The more common the library is, the better it will be<br>
maintained without our (Gluster Community&#39;s) help.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>While this is desirable, we didn&#39;t see any library available for xxhash (<a href="http://cyan4973.github.io/xxHash/">http://cyan4973.github.io/xxHash/</a>) in our distro.<br><br></div><div>I would recommend taking these patches with TODO to use library in future when its available, and continue to have xxhash in &#39;contrib/&#39;. It is not new for us to take code from different libraries and use it for our need and maintain only that part (eg. libfuse). Lets treat this as similar setup.<br><br></div><div>Regards,<br></div><div>Amar<br></div><div><br><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888">
Niels<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
&gt; On 06/27/2017 04:08 AM, Niels de Vos wrote:<br>
&gt; &gt; On Tue, Jun 27, 2017 at 12:25:11PM +0530, Kotresh Hiremath Ravishankar wrote:<br>
&gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We were looking for faster non-cryptographic hash to be used for the<br>
&gt; &gt; &gt; gfid2path infra [1]<br>
&gt; &gt; &gt; The initial testing was done with md5 128bit checksum which was a slow,<br>
&gt; &gt; &gt; cryptographic hash<br>
&gt; &gt; &gt; and using it makes software not complaint to FIPS [2]<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On searching online a bit we found out xxhash [3] seems to be faster from<br>
&gt; &gt; &gt; the results of<br>
&gt; &gt; &gt; benchmark tests shared and lot of projects use it. So we have decided to us<br>
&gt; &gt; &gt; xxHash<br>
&gt; &gt; &gt; and added following files to gluster code base with the patch [4]<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;      BSD 2-Clause License:<br>
&gt; &gt; &gt;         contrib/xxhash/xxhash.c<br>
&gt; &gt; &gt;         contrib/xxhash/xxhash.h<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;      GPL v2 License:<br>
&gt; &gt; &gt;         tests/utils/xxhsum.c<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; NOTE: We have ignored the code guideline check for these files as<br>
&gt; &gt; &gt; maintaining it<br>
&gt; &gt; &gt; further becomes difficult.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Please comment on the same if there are any issues around it.<br>
&gt; &gt;<br>
&gt; &gt; How performance critical is the hashing for gfid2path?<br>
&gt; &gt;<br>
&gt; &gt; What is the plan to keep these files maintained? At minimal we need to<br>
&gt; &gt; add these files to MAINTAINERS and the maintainers need to cherry-pick<br>
&gt; &gt; updates and bugfixes from the original project. The few patches a year<br>
&gt; &gt; makes this a recurring task that should not be forgoten. It would be<br>
&gt; &gt; much better to use this as an external library that is provided by the<br>
&gt; &gt; distributions. We already rely on OpenSSL, does this library not provide<br>
&gt; &gt; an alternative &#39;FIPS approved&#39; hashing that performs reasonably well?<br>
&gt; &gt;<br>
&gt; &gt; Some distributions are very strict on bundling external projects, and we<br>
&gt; &gt; need to inform the packagers about the additions so that they can handle<br>
&gt; &gt; it correctly. Adding an external project to contrib/ should be mentioned<br>
&gt; &gt; in the release notes at the very least.<br>
&gt; &gt;<br>
&gt; &gt; Note that none of the symbols of any public functions in Gluster may<br>
&gt; &gt; collide with functions in standard distribution libraries. This causes<br>
&gt; &gt; for regular problems with gfapi applications. All exposed symbols that<br>
&gt; &gt; get imported in contrib/ should have a gf_ prefix.<br>
&gt; &gt;<br>
&gt; &gt; Thanks,<br>
&gt; &gt; Niels<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [1] Issue: <a href="https://github.com/gluster/glusterfs/issues/139" rel="noreferrer" target="_blank">https://github.com/gluster/<wbr>glusterfs/issues/139</a><br>
&gt; &gt; &gt; [2] <a href="https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Federal_Information_<wbr>Processing_Standards</a><br>
&gt; &gt; &gt; [3] <a href="http://cyan4973.github.io/xxHash/" rel="noreferrer" target="_blank">http://cyan4973.github.io/<wbr>xxHash/</a><br>
&gt; &gt; &gt; [4] <a href="https://review.gluster.org/#/c/17488/10" rel="noreferrer" target="_blank">https://review.gluster.org/#/<wbr>c/17488/10</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt; Thanks and Regards,<br>
&gt; &gt; &gt; Kotresh H R and Aravinda VK<br>
&gt;<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div>