All of 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 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.