Placing the secondary (backup) header closely to the first one is not a
good idea. While this does resolve a power failure induced broken
header, all other problems persist.
If a sector fails, it is not that uncommon that a whole chunk of
consecutive sectors fail (for rotating disks that is). While a recovery
from such a severe failure poses further problems on higher levels, the
risk both headers get damaged is not that small, if they are too close
to each other.
Same holds true when structured data is written over the header
accidently. Depending on the FS and other things both headers could
easily be damaged. Well, if the headers are far apart (start/end) this
could still happen ... true.
The LUKS-header (including key material, which indeed is vital and needs
to be replicated as well) is not as small as you might think, as the
size strongly depends on various parameters.
IMHO a small 1 MB gap is not really an option, as most problems won't be
really solved by this.
It would be possible to place the header at floor(dev_sectors/2) or
something, but this would be pretty complicated, as you'd have to add a
dm-layer to tie together the backing device split by the header or
modify dm-crypt in ther kernel to skip over the gap properly. This seems
a little too nasty for me.
Regards
-Sven
Am 08.02.2016 um 03:06 schrieb f-dm-c@xxxxxxxxxxxxx:
> Date: Mon, 8 Feb 2016 00:17:50 +0100
> From: Arno Wagner <arno@xxxxxxxxxxx>
> I see your problem. The more simple solution would be to
> default to a header copy at the end (people being careless),
> but to allow to explicitely disable/endable it on creation
> and later. In fact, I am very much for adding these options.
That still seems to be more complicated than it needs to be.
> You and (likely) I would run with single headers, but looking
> at the history of this list, that default backup header would
> have helped quite a few people.
Even a second header right after the first---or with an empty gap of a
meg or something---would solve the overwritten-by-OS problem, and even
the bad-disk-sector-in-an-unfortunate-place problem, or the power-
failure-exactly-when-modifying-a-keyslot problem. It takes up so
little space that just always doing it (unless it's a truly tiny
container) would make sense, assuming you're going to change the
format at all from only one header. And it's way easier to do than to
rely on correctly knowing the end of the container when that end might
move. That also means you don't need all kinds of fancy switches and
options to control the behavior, -especially- switches and options
that both installers and gparted etc must now learn to use whenever
the container is being resized. Either leave things with a single
header, or just write a second one with a one meg empty gap between
it and the first one, and call it a day already.
[Putting the backup right at the end of the partition only solves some
problems anyway---anything which moves a potential later partition
backwards could overwrite it, and I've occasionally seen mistakes like
that when repartitioning, depending on the tool. Certain RAID formats
put data near the end of the partition as well, and they often suffer
obscure failures modes because of that as well.]
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
