All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Sagi Grimberg <sagi@grimberg.me>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-block <linux-block@vger.kernel.org>,
	dm-devel@redhat.com, Ilya Dryomov <idryomov@gmail.com>,
	wgh@torlan.ru, Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: LVM snapshot broke between 4.14 and 4.16
Date: Fri, 3 Aug 2018 14:39:32 -0400	[thread overview]
Message-ID: <20180803183932.GA3258@redhat.com> (raw)
In-Reply-To: <20180803152034.GD32066@thunk.org>

On Fri, Aug 03 2018 at 11:20am -0400,
Theodore Y. Ts'o <tytso@mit.edu> wrote:

> On Fri, Aug 03, 2018 at 09:31:03AM -0400, Mike Snitzer wrote:
> > 
> > Debian is notorious for having a stale and/or custom lvm2.
> > Generally speaking, it is recommended that lvm2 not be older than the
> > kernel (but the opposite is fine).
> 
> On Fri, Aug 03, 2018 at 03:31:18PM +0200, Zdenek Kabelac wrote:
> > IMHO (as the author of fixing lvm2 patch) user should not be upgrading
> > kernels and keep running older lvm2 user-land tool (and there are very good
> > reasons for this).
> 
> I'm going to have to strenuously disagree.
> 
> In *general* it's quite common for users to update their kernel
> without updating their userspace.  For example, I as a *developer*, I
> am often running bleeding kernels (e.g., at the moment I am running
> something based on 4.18-rc6 on a Debian testing system; and it's not
> at all uncommon for users to run a newer kernel on older
> distribution).
> 
> This is the *first* I've heard that I should be continuously updating
> lvm because I'm running bleeding edge kernels --- and I would claim
> that this is entirely unreasonable.

It isn't a hard requirement.  But relative to a newer kernel, you simply
cannot deny that a newer lvm2 will work better than on older lvm2.  Not
even speaking about this block regression.  Lessons are learned, fixes
are made, support for the newer kernel's targets are available, etc etc.

That is where the suggestion to keep lvm2 updated along with the kernel
comes from.

It isn't about "oh we regress _all_ the time.. screw users!".

> I'll also note that very often users will update kernels while running
> distribution userspace.  And if you are using Linode, very often
> *Linode* will offer a newer kernel to better take advantage of the
> Linode VM, and this is done without needing to install the Linode
> kernel into the userspace.
> 
> It *used* to be the case that users running RHEL 2 or RHEL 3 could try
> updating to the latest upstream kernel, and everything would break and
> fall apart.  This was universally considered to be a failure, and a
> Bad Thing.  So if LVM2 is not backwards compatible, and breaks in the
> face of newer kernels running older distributions, that is a bug.

Please stop with the overreaction and making this something it isn't.

  reply	other threads:[~2018-08-03 18:39 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 12:26 LVM snapshot broke between 4.14 and 4.16 WGH
2018-08-02 13:31 ` Ilya Dryomov
2018-08-02 13:31   ` Ilya Dryomov
2018-08-02 15:10   ` WGH
2018-08-02 16:41     ` Linus Torvalds
2018-08-02 18:18       ` Ilya Dryomov
2018-08-02 18:32         ` Linus Torvalds
2018-08-02 21:32           ` WGH
2018-08-02 21:39             ` WGH
2018-08-02 21:52               ` Linus Torvalds
2018-08-03 13:31                 ` Mike Snitzer
2018-08-03 15:20                   ` [dm-devel] " Theodore Y. Ts'o
2018-08-03 18:39                     ` Mike Snitzer [this message]
2018-08-03 18:57                       ` Linus Torvalds
2018-08-03 19:06                         ` Mike Snitzer
2018-08-03 19:11                           ` Linus Torvalds
2018-08-03 19:33                             ` Mike Snitzer
2018-08-03 19:22                           ` Linus Torvalds
2018-08-04 10:01                             ` WGH
2018-08-04 17:04                               ` Linus Torvalds
2018-08-04 17:04                                 ` Linus Torvalds
2018-08-04 18:19                                 ` Mike Snitzer
2018-08-04 20:29                                 ` WGH
2018-08-03 19:56                     ` [dm-devel] " Alasdair G Kergon
2018-08-03 20:08                       ` Alasdair G Kergon
2018-08-03 20:42                         ` Linus Torvalds
2018-08-03 21:26                           ` Alasdair G Kergon
2018-08-03 13:31                 ` Zdenek Kabelac
2018-08-03 16:37                   ` Linus Torvalds
2018-08-03 18:54                     ` Mike Snitzer
2018-08-03 18:54                       ` Mike Snitzer
2018-08-03 19:09                       ` Linus Torvalds
2018-08-03 19:30                         ` Mike Snitzer
2018-08-03 19:36                           ` Linus Torvalds
2018-08-04  5:20                           ` [dm-devel] " Theodore Y. Ts'o
2018-08-04  8:36                             ` Zdenek Kabelac
2018-08-04 16:22                               ` Theodore Y. Ts'o
2018-08-04 18:18                                 ` Mike Snitzer
2018-08-04 18:18                                   ` Mike Snitzer
2018-08-04 19:37                                   ` Theodore Y. Ts'o
2018-08-04 19:37                                     ` Theodore Y. Ts'o
2018-08-04 21:48                                     ` Mike Snitzer
2018-08-04 15:19                             ` Mike Snitzer
2018-08-03 19:18                     ` [dm-devel] " Zdenek Kabelac
2018-08-03 19:18                       ` Zdenek Kabelac
2018-08-03 19:30                       ` [dm-devel] " Linus Torvalds

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=20180803183932.GA3258@redhat.com \
    --to=snitzer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sagi@grimberg.me \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=wgh@torlan.ru \
    --cc=zkabelac@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.