From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com
 [IPv6:2a00:1450:400c:c09::22a])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Thu,  4 Feb 2016 09:38:02 +0100 (CET)
Received: by mail-wm0-x22a.google.com with SMTP id l66so106019899wml.0
 for <dm-crypt@saout.de>; Thu, 04 Feb 2016 00:38:02 -0800 (PST)
References: <CAFnMBaRfu93jkgmZ_vLDChF7Uv-dCE6dNN6YkSxU3EFvn8iHtg@mail.gmail.com>
 <56B20C05.7080307@gmail.com> <56B25914.5090204@whgl.uni-frankfurt.de>
From: Milan Broz <gmazyland@gmail.com>
Message-ID: <56B30DE8.1060502@gmail.com>
Date: Thu, 4 Feb 2016 09:38:00 +0100
MIME-Version: 1.0
In-Reply-To: <56B25914.5090204@whgl.uni-frankfurt.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] The future of disk encryption with LUKS2
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: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
Cc: dm-crypt <dm-crypt@saout.de>

On 02/03/2016 08:46 PM, Sven Eschenberg wrote:
> Really looking forward to the discussion, Milan.
> 
> Personally I'd love to see FEC extensions in a v2 on-disk-format.

Hi Sven,

If you mean FEC (forward error correction, using Reed-Solomon code)
support for dm-verity, that's not directly related to LUKS2. In fact
it is kernel feature (and it will be supported in next major veritysetup version,
just the FEC branch need a lot of cleanup before I can merge it).

Anyway, I do not like much the way how it implemented but it is already
in mainline kernel so it is just waste of time to complain again :)

(Read dm-devel if you are interested, thread
"dm verity: add support for error correction" from November last year.)

I have never thought of using FEC for dm-crypt, anyway, if it is implemented
as a separate layer below dmcrypt, it could work (not the case today,
FEC is integral part of dm-verity).

Anyway, if you have some real use cases for FEC (and specifically some
real-world examples of data corruption it can fix), please share it, I am
very interested to see that. (I know the problem exist and that FEC could
be useful but seems nobody is able provide any hard data...)

Milan