linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: matthew patton <pattonme@yahoo.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Saying goodbye to LVM
Date: Wed, 7 Feb 2018 21:53:55 +0000 (UTC)	[thread overview]
Message-ID: <215644475.5896991.1518040435407@mail.yahoo.com> (raw)
In-Reply-To: 215644475.5896991.1518040435407.ref@mail.yahoo.com

Xen wrote:
 

>  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 
>...  seems also  fraught with peril.
>
>  So if you're on Xenial, you are stuck with the features but without the  protection.

Don't use a distro that is sloppy about looking out for the end-user? I can't speak for how 'stable' LVM is in their releases or if anyone expends effort to identify "golden" releases vs "preview / dangerous" releases...

>  particular there is a quagmire of situations ... only get out of the situation with dmsetup remove, 
> but I didn't  know this at first.

Which is part of the problem, really. You were trying to do 'expert' things without the requisite background or knowledge. Now granted we learn by shooting ourselves in the foot from time to time but the blood loss is never pleasant. You either learn quickly or you pick another tool that has spent the time to put proper dependency/protection in place such that 'EXPERTS ONLY NEED APPLY' is not the phrase of the day.

I think LVM does need to step it up in putting proper safeguards in place before calling a feature release-worthy. If you have a feature then it is REQUIRED that it also have ALL of the necessary dependency check logic fully implemented. Otherwise it is a BUG and has no business being published in a manner that careless distros can activate it.

If multiple PVs show up with duplicate ID or other bad characteristics there needs to be a well documented mechanism for rectifying the situation written from the POV of a user/sysadmin and not a developer who happens to know all the inner workings. Are metadata time-stamped or otherwise versioned so even if you see what looks to be a conflict the 'age' of the metadata can give an indication which one is likely to be correct? If not, why not?

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

That's retarded. Is this a correct characterization? If so, how did that get past the release audit?

 

       reply	other threads:[~2018-02-07 21:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <215644475.5896991.1518040435407.ref@mail.yahoo.com>
2018-02-07 21:53 ` matthew patton [this message]
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
2018-02-07 22:10       ` Xen

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=215644475.5896991.1518040435407@mail.yahoo.com \
    --to=pattonme@yahoo.com \
    --cc=linux-lvm@redhat.com \
    /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).