From: Milan Broz <mbroz@redhat.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM
Date: Tue, 20 Sep 2011 15:13:24 +0200 [thread overview]
Message-ID: <4E789174.1090607@redhat.com> (raw)
In-Reply-To: <20110920114724.GA21251@tansi.org>
On 09/20/2011 01:47 PM, Arno Wagner wrote:
> The encryption can be established as long as the header and
> at least on ekeyslot are intact. If you cut the power just in the
> microsecond while a keyslot is written you would damage that
> keyslot. If it was your only one and you do not have a header backup,
> then you would have total data loss. That is the only scenario
> I can think of. In normal operation, the header is not written.
Yes, for open and normal activation/deactivation nothing is written
to LUKS header.
And all keyslot operation are done through sync|direct io path
(avoids cache) so it should hit hw immediately.
> Keep in mind that LVM adds to the complexity when you have to do
> data recovery when something went wrong. Other that that it sounds
> like a good approach.
You can say that the same for MD.
Btw LVM has much better recovery abilities than other systems.
Just people are not so familiar with them.
I tried to show it some time ago in some talk,
you can check how easy is to recover complete disaster
(slides are not perfect, missing most of the comments)
http://mbroz.fedorapeople.org/talks/LinuxAlt2009_2/
But use of lvm2 is completely optional.
What is complex is incredible complicated lvm2 user interface (CLI),
here I fully agree. But even for notebook, pvmove or online resize
is useful sometimes.
>> (I keep daily backups of $HOME and of essential system settings, the
>> rest can be reinstalled if needed, but I'd prefer not to have to spend a
>> few days recovering everything if I had a hard reset or something like
>> that.)
>
> You will not damage the encrypted data in normal operation.
> All the header-damages reported were done during installation,
> repartitioning, moving partitions, etc.
These days is my favorite to LUKS damage bad MD resync
(usually mistake in partition change or MD metadata format change).
(No idea why such problems come in batches to lists :)
Milan
next prev parent reply other threads:[~2011-09-20 13:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 10:36 [dm-crypt] (More) Questions about LUKS / LVM Robbie Smith
2011-09-20 10:52 ` Quentin Lefebvre
2011-09-20 11:47 ` Arno Wagner
2011-09-20 13:13 ` Milan Broz [this message]
2011-09-20 14:14 ` Arno Wagner
2011-09-20 14:52 ` Milan Broz
2011-10-03 6:17 ` Luca Berra
2011-10-03 10:55 ` Arno Wagner
2011-09-20 15:21 ` Alexander Koch
2011-09-20 16:12 ` Milan Broz
2011-09-20 17:41 ` Arno Wagner
2011-09-20 18:06 ` Karl O. Pinc
2011-09-20 18:19 ` Milan Broz
2011-09-21 10:22 ` Arno Wagner
2011-09-21 16:14 ` Dragan Milivojevic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E789174.1090607@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.