[linux-lvm] Saying goodbye to LVM

[Xen]

Gionatan Danti schreef op 07-02-2018 19:42:

> I am both a LVM/ThinLVM and ZFS heavy user, so I hope to be impartial 
> here...
> 
> LVM and its lvmthin counterpart are *rock solid* in my experience,
> except in the (very) edge case of full thin pool (this was lengthly
> discussed in the past, and both Zednek and Jonathan gave accurate
> suggestions on how to avoid that).
> 
> However, in my experience, the only distribution which keep updated
> version of lvm kernel and user space utilities is RHEL/CentOS. I found
> Debian and Ubuntu based distributions particularly *bad* at managing
> LVM and device mapper targets in general.

This is the reason for the problems but LVM released bad products all 
the same with the solution being to not use them for very long, or 
rather, to upgrade.

Yes Ubuntu runs a long time behind and Debian also.

As a user, I can't help that, upgrading LVM just like that to have less 
"there is a pit here but we won't tell you about that" simply seems also 
fraught with peril.

For example, upgrading LVM slightly to 160 caused udev problems I didn't 
have before.

So you can blame the distributions, you can also blame features being 
released first and proper protection only being added much later.

So if you're on Xenial, you are stuck with the features but without the 
protection.

In particular there is a quagmire of situations you can end up with wrt 
the shielding and dual activation of the same vg, many times of which 
you can only get out of the situation with dmsetup remove, but I didn't 
know this at first.

Or you end up in the situation where a PV is missing and you cannot edit 
the VG, but in order to remove the PV you have to edit the VG.

A missing cache device cannot be removed without the missing cache 
device being present.

I meant to say, you can have 2 disks out of sync and resolving it is not 
possible other than by editing config on disk and doing vgcfgrestore.

But you can't do vgcfgrestore without removing a missing PV first.

There is a huge amount of chicken and egg problems because physically a 
VG sits inside a PV but logically a PV sits inside a VG and this 
constantly causes issues.

LVM just has conceptual problems.

> That said, ZFS really is outstanding (especially checksum and
> compression, albeit is sorely lacks reflinks). I really have high
> hopes for stratis (https://github.com/stratis-storage), which plan to
> provide ZFS-like feature using stacked device mapper targets (which
> our beloved LVM targets on top).

I cannot write more yet because I don't have ZFS setup yet.

I don't like ZFS too much because it's opaque and Linux support seems to 
be flimsy (for example boot support) and the only good documentation is 
Oracle but it often does not apply.