> Date: Mon, 8 Feb 2016 05:32:14 +0100
> From: Sven Eschenberg <sven@xxxxxxxxxxxxxxxxxxxxx>
> Of course, that's what I usually do anyway. But we'll have to at least
> consider an average user aswell, having a normal desktop, using a magic
> mumbo jumbo installer with LVM on top of dm-crypt setup. It's not about
> covering your or my use case, but rather those of as many users as
> possible, without sacrificing i.e. security though.
Right. And the average user is using an installer that might want to
expand a partition. If that doesn't work, LUKS is a nonstarter there.
Even if it -could- work, but installers suddenly have to be aware of
which version of LUKS they're talking so they can supply magic random
options, then that's a situation where it's very likely that installers
will screw it up. And installers screwing it up is -precisely- why
we're talking about having header redundancy in the first place.
Let's please not -encourage- screwups of rare-and-not-well-tested
actions that can lose data.
Also, the -average- user is not experiencing multiple megabytes of
corruption at the beginning of partitions. C'mon. The -average-
user is experiencing a bad Ubuntu installer deciding to put a
partition table on top of a LUKS header or some other handful-
of-sectors corruption. Not a megabyte, much less ten or more.
> Of course overcomplicating things is not an option. But you should
> always remember: A damaged header is a total loss, a damaged fs can
> quite often be recovered easily enough. And other tools need 'special
> instructions' for every fs, dm-layer and task. There's no generic
> resize() IOCTL for all your block layers.
But all the rest of them do assume that they can use the entire
container unless you say not to, and that expansion works.
Every single layer of what -I- do -is- resizeable---I can resize
partitions, and LVM, and LUKS, and ext4. Any solution in which LUKS
can no longer be resized (especially grown) means that LUKS will be
instantly heaved overboard in favor of something else that can,
because it's the only thing in the stack which would fail that test.
> I don't mind keeping it simple. Really simple and secure was already
> mentioned: You do have a backup anyway, just recreate the container and
> pull back the backup and you are done ;-). Resizing (growing) is just a
> convenient thing to do.
Did you actually read my original message? As I said, in my use case,
it is simply not an option to "back up, blow away, resize, and put
back," because having to do that offline means multiple days of
downtime to do two entirely-pointless block-level copies, one in each
direction, on a -dismounted- FS. Those multiple days are clearly not
required if LUKS can grow---I've done it before without downtime,
precisely because all layers can grow.
Let me try to summarize: The reason we are having this conversation
at all is because proposals to increase the robustness of LUKS headers
almost immediately allowed the perfect to become the enemy of the good
---to the point where increasing their robustness lead to comments like
"well, let's just kill the ability of LUKS to grow because it's too
hard to figure out how to preserve the multiple headers in that case."
That is a big warning sign that the proposal is too complex.
One other thing: One problem with putting a redundant header at the
end is that something which resizes the container out from under LUKS
(prime candidate for "something just corrupted the container") means
that LUKS (and any user trying to find that header by hand) has no
idea where to look for it, short of scanning every single block on
the disk for something that looks like a header. Putting it near the
front means that LUKS either has only one option, or at the very least
only a very small number of blocks to scan, before it concludes that
it's either found the header or there isn't one.
[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
(where "gap" means "really unused---don't give it to the FS" or maybe
even "put a backup header every n megabytes all through the gap"), and
have --redundant-header-at=[none|offset-in-meg] option for those who
insist on putting it somewhere magic. Now LUKS has at most 3 places
to look even if it doesn't know how big the FS was, or a scan if the
user used --redundant-header-at. But the code is still very simple,
online resizing works the way it always did, and people who are super-
paranoid about corrupting a gig at the start of their partition can
throw away an entire gig by pushing it farther in or something. Or
putting it at the end, but then LUKS has to treat the gap as actual FS
storage area, which is again more complicated, so I don't recommend it.]
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
