Re: [dm-crypt] (More) Questions about LUKS / LVM

[Luca Berra <bluca@comedia.it>]

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