[dm-crypt] The future of disk encryption with LUKS2

f-dm-c at media.mit.edu f-dm-c at media.mit.edu
Mon Feb 8 04:43:24 CET 2016

    > Date: Mon, 8 Feb 2016 03:46:27 +0100
    > From: Sven Eschenberg <sven at whgl.uni-frankfurt.de>

    > If a sector fails, it is not that uncommon that a whole chunk of 
    > consecutive sectors fail (for rotating disks that is).

Oh, come on.  A one-meg gap is 256 4K sectors and 1024 1K sectors.

I've never seen anything take out more than a handful of sectors
adjacent to each other unless the disk has completely failed.
Anything that's chewing up multiple megs or tens of megs at the start
of your FS is likely to destroy any other random parts of it as well.

Okay, how about a -10- meg gap?  That enough?

If you need resiliency from massive corruption like that, use a header
backup -on other media-, and -also- an actual backup of the FS.

Complicating LUKS to the point where resizing becomes fraught and
difficult to handle and other tools need all kinds of special
instructions to solve a problem where the disk is already in severe
distress or something's written tens of megs of garbage all over it
seems pointless.

The (potentially solvable) problem we've seen most on this list is not
massive disk failure, but OS's that decide to overwrite a sector or
two near the front.  So maybe we'll be extravagent and use 10 megs of
clear space between the two copies---that's still absolutely in the
noise on any reasonable disk, while being dead simple to implement,
does not require any knowledge of the ultimate container size, does
not require motion if the size changes, and will withstand almost any
conceivable failure except someone doing "dd if=/dev/zero of=part" and
then not noticing until a minute later---at which point, it's time to
go to the backups anyway.  And it doesn't involve hairing up the
options to enable/disable/move around/dance a jig with where the
backup header is stored.  Keep it simple.

More information about the dm-crypt mailing list