DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM
Date: Tue, 20 Sep 2011 16:14:31 +0200	[thread overview]
Message-ID: <20110920141431.GA23126@tansi.org> (raw)
In-Reply-To: <4E789174.1090607@redhat.com>

On Tue, Sep 20, 2011 at 03:13:24PM +0200, Milan Broz wrote:
> 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.

Indeed. Especially with the incredible mess that MD superblock
positioning is. I only use superblock format 0.9 for that
reason. Then I at least know it is at the end and that the 
kernel can auto-detect. They should have let it stay 
there. That would have been massively better than the insanity 
of having 3 possible positions.
 
> 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/ 

Nice nonetheless!
 
> 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.

But strictly not necessary. I usually test my backup and restore 
procedure when having to resize something. (Yes, I do 2 current 
backups and a very careful verify before.)

> >> (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 :)

Probably because default metadata format for mdadm is now 1.2
(places superblock at 4k from start). Personally I have never 
damaged anything with MD resync but I only use metadata 0.90. 

Seems to me the kernel folks are not happy woth the > 0.90 
formats either or autodetection would work for them.

No idea what I am going to to when I hit the 2TB size 
restriction on the 0.90 metadata format, but that will still
be a while. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

  reply	other threads:[~2011-09-20 14:14 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
2011-09-20 14:14     ` Arno Wagner [this message]
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=20110920141431.GA23126@tansi.org \
    --to=arno@wagner.name \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox