From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Sun, 20 Sep 2009 20:11:14 +0200 (CEST)
Received: from int-mx08.intmail.prod.int.phx2.redhat.com
	(int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8KIBDSb001586
	for <dm-crypt@saout.de>; Sun, 20 Sep 2009 14:11:13 -0400
Received: from [10.36.8.23] (vpn2-8-23.ams2.redhat.com [10.36.8.23])
	by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id n8KIBC11031355
	for <dm-crypt@saout.de>; Sun, 20 Sep 2009 14:11:13 -0400
Message-ID: <4AB6703F.90804@redhat.com>
Date: Sun, 20 Sep 2009 20:11:11 +0200
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <200909182039.44953.dmcrypt-list@tpesonen.net>	<4AB3CE76.5040502@redhat.com>	<20090919165148.GA5619@fancy-poultry.org>	<4AB52A50.1060503@redhat.com>	<20090920112817.GA5778@fancy-poultry.org>
	<20090920150945.GA8432@fancy-poultry.org>
In-Reply-To: <20090920150945.GA8432@fancy-poultry.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] Question on LUKS master key digest and its effect on
 security
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

Heinz Diehl wrote:
> On 20.09.2009, Heinz Diehl wrote: 
> 
>> Today I upgraded to the latest device-mapper, and the buffer i/o errors
>> are completely gone.
> 
> Have to correct myself, after some hours there are some buffer i/o errors
> in the logs again. It's a lot less errors as it has been before, but they
> are not gone...

Sure, because libdevmapper is still not completely udev aware:-)

Anyway, because I do not want to spent too much time with this bug
(I am sure you are not only one who see this) I moved that
error workaround after first 1 sec waiting, this should be similar to
behaviour in 1.07 but do not adds sleep when not needed)

Please can you retest with current svn code?

And btw code should be in stable state, I just need to find some time
to implement some new features before releasing stable candidate.

Milan