archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <>
To: LVM general discussion and development <>
Cc: Xen <>
Subject: Re: [linux-lvm] Saying goodbye to LVM
Date: Wed, 07 Feb 2018 22:19:28 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Il 07-02-2018 21:37 Xen ha scritto:
> 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.

As a CentOS user, I *never* encountered such problems. I really think 
these are caused by the lack of proper integration testing from 
Debian/Ubuntu. But hey - all key LVM developers are RedHat people, so it 
should be expected (for the better/worse).

I can not say anything about lvmcache, though.

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

True. I never use it with boot device. LVM and XFS are, on the other 
hand, extremely well integrated into mainline kernel/userspace 

Hence my great interest in stratis...

Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. -
email: -
GPG public key ID: FF5F32A8

  reply	other threads:[~2018-02-07 21:19 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
2018-02-07 21:19     ` Gionatan Danti [this message]
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).