archive mirror
 help / color / mirror / Atom feed
From: Xen <>
Subject: Re: [linux-lvm] Saying goodbye to LVM
Date: Wed, 07 Feb 2018 21:37:26 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 

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 (, 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.

  parent reply	other threads:[~2018-02-07 20:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 16:45 [linux-lvm] Saying goodbye to LVM Xen
2018-02-02  2:49 ` John Stoffel
2018-02-07 18:42 ` Gionatan Danti
2018-02-07 19:21   ` pattonme
2018-02-07 20:37   ` Xen [this message]
2018-02-07 21:19     ` Gionatan Danti
2018-02-07 22:10       ` Xen
     [not found] <>
2018-02-07 21:53 ` matthew patton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).