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 R7SOy_qAlmqw for ; Mon, 3 Oct 2011 08:25:10 +0200 (CEST) Received: from maude.comedia.it (maude.comedia.it [77.93.254.181]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 3 Oct 2011 08:25:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by maude.comedia.it (Postfix) with ESMTP id 8B86686FD1 for ; Mon, 3 Oct 2011 08:17:41 +0200 (CEST) Received: from maude.comedia.it ([127.0.0.1]) by localhost (maude.comedia.it [127.0.0.1]) (amavisd-new, port 10025) with LMTP id WggE+td9HlTr for ; Mon, 3 Oct 2011 08:17:36 +0200 (CEST) Date: Mon, 3 Oct 2011 08:17:36 +0200 From: Luca Berra Message-ID: <20111003061736.GA30376@maude.comedia.it> References: <1316515022.7965.31.camel@zarniwoop> <20110920114724.GA21251@tansi.org> <4E789174.1090607@redhat.com> <20110920141431.GA23126@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline In-Reply-To: <20110920141431.GA23126@tansi.org> 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 04:14:31PM +0200, Arno Wagner wrote: >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. Please, before speaking against something do some research. There is no reason on earth to use 0.90 superblocks nowadays. Even if it seems easier to do that with in-kernel autodetection and being able to access two halves of a mirror like they were a single disk, the drawbacks are unacceptable. In kernel autodetection is not smart enough and can backfire, just plug a usb or e-sata device with an md superblock with the same md minor number as your root mirror. It has been left as is for historical reasons, the proper fix is using an initramfs, without bloating the kernel with unneeded code. accessing a raid member like it was a non raid device is also a bad idea. it is better to force assembly of a degraded array. Putting metadata at the end also raises a lot of confusion with partition tables, which are at the start of the disk. If you create a partition ending at the end of the disk, then add the partition to an md array, 0.9 metadata would be at the same location than if you added the whole device to the array. If you create an raid 0/5/6 array using whole devices then partition it, the kernel will see a broken partition table on one or more of the component devices. This extends to any other kind of data besides partition. Add udev and event-driven activation of disks (especially in its first very early stages) and people started having the weirdest problems. Then there are limitations on number of components and array sizes which are possible to reach, and have already been reached by a number of users. The only reason nowadays to keep metadata at the end of a device is a limitation of grub 1, which cannot boot otherwise. The latter case is covered by metadata 1.0, which addresses most of the limitations of 0.9, still keeping metadata at end in order to please grub. Then in order to protect the innocent, a schema with metadata at the start was implemented, first attempt was 1.0 (which imho was a bad idea). It puts metadata at the very beginning of disk, which poses metadata at risk of being overwritten (since that location is often used by mbr and partition table). In order to avoid that metadata 1.2 was devised, it is stored at beginnning of disk, with an offset from the start, in order for it to be somewath protected. There is also room on the disk to store some form of boot code. Consensus now is use metadata 1.2 for almost everything except for mirrors containing /boot, which need to use 1.0. Regards, L. -- Luca Berra -- bluca@comedia.it