Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp795560imm; Fri, 3 Aug 2018 11:40:39 -0700 (PDT) X-Google-Smtp-Source: AAOMgpenjYdN/omFembjzlB+mOEjgCRNyZrC6E8UsxLCcKiI0b+ozETXOL2pYfqpM2ZFDDzDwKm/ X-Received: by 2002:a63:d401:: with SMTP id a1-v6mr4826841pgh.414.1533321639459; Fri, 03 Aug 2018 11:40:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533321639; cv=none; d=google.com; s=arc-20160816; b=OLkfTv9/Xbl2NtAiT7DTejGA4zUlBJLxCDK7Dp81cZuzm384wjM6I05QjndwzQzMd5 UWDyhY8NY6xCwcGuMtvwLg8gIk75UvZf6SGNAD3QJfkmn5+Ra5qN5RSxDvon7eI9oZJs UTp9YmLzK2JRR4haXS3JndVVX3EVSmzNoT6qjXM0HF8Kq5ixty+3EQxQXHEDVlvQwN1n RFuumooyK68hZw0rA/ciPMfxGCACzPntQ6Tpv4PQwkcmEU5GJlC3EJEEa/jHjeJB64bo 14WW3PDcrY2xavFiuPFHjUL06KODR289sMXNdO1rE+0uGOcoNTDeJGDqhPS0TF0Wnmkf 7dCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:to :from:date:arc-authentication-results; bh=P+N6KiajrVEUwlSv7D+d8FdMwCZZDN/1it2I/hixtFU=; b=PqKvJgBVG7JOqgRSzuUtkoxsGpsDhSYlI/yqgpV1xM+mDsNAFDUkasQ1jo7und9Yhu uCU5BQLB7ccMxfhg+2w4CdHc3JZ/NXE7+UvDP5jWTh3fOWu64uLuQq2pE2tfwAwkprTF LbFXMCuyDqZ1k6GGcTjJUh0A/cjybar+SUwVDtPaLi37VMr7k7F9X/895QgjNQY68vNm fZTpiJoD6ipAYaCTgqtk9yxRVfrVuCF2zXZ3+NX2oXcj6rxiiCe6zKsyiVHA/o60K5/2 59ErG+y41spKSbBUc5KaIFfJzUBc3kjDZp6kyLkhcGfu0obpf3Ot/UxOggAHZEuaKBjW bTzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u7-v6si6269693pfb.227.2018.08.03.11.40.24; Fri, 03 Aug 2018 11:40:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729916AbeHCUhF (ORCPT + 99 others); Fri, 3 Aug 2018 16:37:05 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:51606 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728139AbeHCUhF (ORCPT ); Fri, 3 Aug 2018 16:37:05 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F04588197021; Fri, 3 Aug 2018 18:39:35 +0000 (UTC) Received: from localhost (unknown [10.18.25.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3AF767C4F; Fri, 3 Aug 2018 18:39:33 +0000 (UTC) Date: Fri, 3 Aug 2018 14:39:32 -0400 From: Mike Snitzer To: "Theodore Y. Ts'o" , Linus Torvalds , Jens Axboe , Sagi Grimberg , Linux Kernel Mailing List , linux-block , dm-devel@redhat.com, Ilya Dryomov , wgh@torlan.ru, Zdenek Kabelac Subject: Re: LVM snapshot broke between 4.14 and 4.16 Message-ID: <20180803183932.GA3258@redhat.com> References: <93bff248-6897-4867-841b-2dace11597de@torlan.ru> <1ec0a220-d5b0-1c27-e63b-c4d3f4ce9d77@torlan.ru> <20180803133102.GA3092@redhat.com> <20180803152034.GD32066@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180803152034.GD32066@thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 03 Aug 2018 18:39:36 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 03 Aug 2018 18:39:36 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'msnitzer@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 03 2018 at 11:20am -0400, Theodore Y. Ts'o 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.