From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBfM4MhFQYBk for ; Tue, 20 Sep 2011 16:14:32 +0200 (CEST) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 20 Sep 2011 16:14:32 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-163-71.dclient.hispeed.ch [84.74.163.71]) by v4.tansi.org (Postfix) with ESMTPA id 3D114206343 for ; Tue, 20 Sep 2011 16:14:32 +0200 (CEST) Date: Tue, 20 Sep 2011 16:14:31 +0200 From: Arno Wagner Message-ID: <20110920141431.GA23126@tansi.org> References: <1316515022.7965.31.camel@zarniwoop> <20110920114724.GA21251@tansi.org> <4E789174.1090607@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E789174.1090607@redhat.com> Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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