From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:32924)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1TwDiG-0000eQ-2F
	for qemu-devel@nongnu.org; Fri, 18 Jan 2013 10:18:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1TwDiD-0003zI-8e
	for qemu-devel@nongnu.org; Fri, 18 Jan 2013 10:18:35 -0500
Received: from nodalink.pck.nerim.net ([62.212.105.220]:44501
	helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1TwDiD-0003z9-0i
	for qemu-devel@nongnu.org; Fri, 18 Jan 2013 10:18:33 -0500
Date: Fri, 18 Jan 2013 16:19:02 +0100
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20130118151902.GA6087@irqsave.net>
References: <1358437897-24251-1-git-send-email-benoit@irqsave.net>
	<1358437897-24251-8-git-send-email-benoit@irqsave.net>
	<50F879E1.2060507@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <50F879E1.2060507@redhat.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC V6 07/11] quorum: Add quorum mechanism.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com

> Hmm, adler32() is basically a weak hashing mechanism; are you sure you
> won't have any false collisions?  Furthermore, how does this compare
> with the series for adding deduplication, which uses much
> stronger/longer hashes, but where those take more time to compute?  Is
> there any way you can share efforts between the two series?

I agree that using sha256 would be a better option as it will not be call=
ed
frequently.
However the call to gnutls is a one liner so it's likely not shareable.
The configure would need to be modified to require gnutls and It likely n=
ot
factorisable either.

I'll change the code to use sha256.

Regards

Beno=EEt


>=20
> > +    /* get the index of the first successfull read */
>=20
> s/successfull/successful/ (several times in this patch)
>=20
> --=20
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>=20