linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Xen <list@xenhideout.nl>
Subject: Re: [linux-lvm] Saying goodbye to LVM
Date: Wed, 07 Feb 2018 22:19:28 +0100	[thread overview]
Message-ID: <080fb0a6027e5b15e004de36c05a852a@assyoma.it> (raw)
In-Reply-To: <74c6270dfd9e5f5784556593a706f24a@xenhideout.nl>

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

Hence my great interest in stratis...
Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
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] <215644475.5896991.1518040435407.ref@mail.yahoo.com>
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=080fb0a6027e5b15e004de36c05a852a@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=list@xenhideout.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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