> 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
