[dm-crypt] KISS (was disappearing luks header and other mysteries)
Ballarin.Marc at gmx.de
Sun Sep 21 16:29:28 CEST 2014
Am 21.09.2014 um 11:58 schrieb Arno Wagner:
> On Sat, Sep 20, 2014 at 02:29:43 CEST, Sven Eschenberg wrote:
>> Well, it is not THAT easy.
> Actially it is.
>> If you want resilience/availability, you'll need RAID. Now what do you put
>> ontop of the RAID when you need to slice it?
> And there the desaster starts: Don't slice RAID. It isnot a good
>> Put a disklabel/partition on
>> top of it and stick with a static setup or use LVM which can span multiple
>> RAIDs (and types) supports snapshotting etc. . Depending on your needs and
>> usage you will end up with LVM in the end. If you want encryption, you'll
>> need a crypto layer (or you put it in the FS alongside volume slicing).
>> Partitions underaneath the RAID, not necessary if the RAID implementation
>> can subslice physical devices and arrange for different levels on the same
>> disk. Except unfortunately, when you need a bootloader.
>> I don't see any alternative which would be KISS enough, except merging the
>> layers to avoid collissions due to stacking order etc. . Simple usage and
>> debugging for the user, but the actual single merged layer would be
>> anything but KISS.
> You miss one thing: LVM breaks layereing and rather badly so. That
> is a deadly sin. Partitioning should only ever been done on
> monolithic devices. There is a good reason for that, namely that
> parition-raid, filesystems and LUKS all respect partitioning per
> default, and hence it actually takes work to break the container
I don't see how LVM breaks layering. In theory it replaces partitioning,
but in practice it is still a very good idea to use one single partition
per visible disk as a (more or less) universally accepted way to say
"there is something here, stay away!". The same applies to LUKS or plain
fiilesystems. No reason to put them on whole disks.
The megabyte or so that you sacrifice for the partition table (plus
alignment) is well spent. Partitions do not cause any further overhead,
as unlike device mapper, they do not add a layer to the storage stack
(from a users POV they do, but not from the kernel's).
Note that there is little reason to use mdraid for data volumes nowadays
(that includes "/" when using a proper initramfs). LVM can handle this
just fine and unlike mdadm has not seen any major metadata changes, or
even metadata location changes, in the last years. But I'm not sure, it
can offer redundancy on boot devices. In theory it should, if the boot
loader knows how to handle it, but I have never tested it. This is
basically the "merging of layers" that Sven talked about.
Btrfs and ZFS push this even further, and while they are complex beasts,
they actually eliminate a lot of complexity for applications and users.
Just look at how simple, generic and cheap it becomes to create a
consistent backup by using temporary snapshots, or to preserve old
versions by using long lived snapshots. This can replace application
specific backup solutions, that cost an insane amount of money and whose
user interfaces are based on the principles of Discordianism (so that
training becomes mandatory).
Also: Stay away from tools like gparted or parted. Resizing and, above
all, moving volumes is bound to cause problems. For example, looking at
John Wells issue from august 18th (especially mail
CADt3ZtscbX-rmMt++aXme9Oiu3sxiBW_MD_CGJM_b=t+iMaerQ), the most likely
culprit really wasn't LVM, but parted. It seems to have set up scratch
space where it should not have.
Once resizing or volume deletions/additions are necessary, LVM is
actually the much simpler and more robust solution. Resizing as well as
deletions and additions in LVM are well defined, robust and even
undoable (as long as the filesystem was not adjusted/created). At work,
we use that on 10,000s of systems.
Lastly, it should be noted, that complex storage stacks like
MD-RAID->LVM->LUKS->(older)XFS can have reliability issues due to stack
exhaustion (you can make it even worse by adding iSCSI, virtio,
multi-path and many other things to your storage stack). When and if
problems occur, depends strongly on the architecture, low-level drivers
involved and the kernel version, but it is likely to happen at some
point. Kernel 3.15 defused this, by doubling the stack size on x86_64.
(btw: That, and not bad memory, might actually be the most common cause
behind FAQ item 4.3).
More information about the dm-crypt