From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <foner@media.mit.edu>
Received: from bella.media.mit.edu (bella.media.mit.edu [18.85.58.176])
 by mail.server123.net (Postfix) with ESMTP
 for <dm-crypt@saout.de>; Mon,  8 Feb 2016 21:05:23 +0100 (CET)
From: f-dm-c@media.mit.edu
In-reply-to: <20160208165124.GD5543@tansi.org> (message from Arno Wagner on
 Mon, 8 Feb 2016 17:51:24 +0100)
References: <56B5356B.3030704@whgl.uni-frankfurt.de>
 <20160206025854.GA5986@tansi.org>
 <56B56605.4030907@whgl.uni-frankfurt.de>
 <20160207070958.35502402ED@darkstar.media.mit.edu>
 <20160207231750.GB29215@tansi.org>
 <20160208020631.E16BA402ED@darkstar.media.mit.edu>
 <56B80183.60006@whgl.uni-frankfurt.de>
 <20160208034324.790B2402ED@darkstar.media.mit.edu>
 <56B81A4E.9090909@whgl.uni-frankfurt.de>
 <20160208060924.9CCC5402ED@darkstar.media.mit.edu>
 <20160208165124.GD5543@tansi.org>
Message-Id: <20160208200522.8405A402ED@darkstar.media.mit.edu>
Date: Mon,  8 Feb 2016 15:05:22 -0500 (EST)
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: dm-crypt@saout.de

    > Date: Mon, 8 Feb 2016 17:51:24 +0100
    > From: Arno Wagner <arno@wagner.name>

    > On Mon, Feb 08, 2016 at 07:09:24 CET, f-dm-c@media.mit.edu wrote:
    > [...]

    > > [For example, and to take into account "OMG but what if massive giant
    > > corruptions and/or mislayered tables at start," have these as defaults:
    > > (a) FS < 10 meg --> no extra header
    > > (b) 10 meg < FS < 100 meg --> extra header after 1 meg gap
    > > (c) 100 meg < FS < 10 gig --> extra header after 10 meg gap
    > > (d) fs > 10 gig --> extra header after 100 meg gap

    > That strikes me as an exceedingly bad idea as it will be 
    > unpredictable to those users that need it. And I do not like
    > different places for md-RAID 1.x format superblocks one bit.
    > We should pick one thing, make it otional (but on by default)
    > and stick with it, so users do know where it is, regardless 
    > of other parameters.

I only said that to try to quell the "but it's -not enough- of an
offset," because someone can always spin an even-worse-case where
whatever you do just isn't enough.  As I originally said, the least
complicated thing seems to be to just repeat the header right after
the original header, perhaps with a megabyte or so of padding between
them.  (But even if you had these extra headers at varied offsets,
you only have 3 different places to look, and if it's not a header,
it will look all wrong, including failing a checksum.)