Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp674162imm; Fri, 3 Aug 2018 09:38:58 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd8k2/m2bTxdoCn/iq02wZcsl6ne4zeaU/EOftu0oelrvpdHBQZzB+UgmVvDj88b9UgIvEk X-Received: by 2002:a63:5350:: with SMTP id t16-v6mr4487348pgl.196.1533314338111; Fri, 03 Aug 2018 09:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533314338; cv=none; d=google.com; s=arc-20160816; b=N+6V6agmuur/XdsYPOC//BJhdg0x3pNa00A1yxAjCZgXksOmaD8QQcQhpS+s51I6Yh 1+GNvvQiMcbew2A80doeSSwBz85wPt2k6iaWykCTzvb0V2tfIPUVyebur9pZwCQRoOap itXTGWBgUYDIFc2pH/3CPe8YOVfYXnUvPppULqCu/kpWQHPhQ9t/v/POIVJRSHs0D8ei b+fMAjE3z0FLFu66r/qQlSMMPz3C/zD9qNIQzbXOsIWnvbZfCQI6UDy+admZbBZQ1C8l XOt1F+WmnCvmm6jRrQ8VcpTCcYIjRAgo/UJokqUCYuwLMWRxPa41B7/AnaBTSkGY+D89 YCMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=NhGHLCuCDrC3t2YKc6PPYC7XNF/mP/dEl9RYiSyhq9E=; b=V2ONL6o1eGXUxVOlrAo7n3RqYcR3Mpit14ymTiDnbdmcbaQ4EuIuZud9QvGEHarikc LTrtbGOEj2RPjpnBsGCsYZFk1bN4IGWjYxNJGYqwsa9rcD7CSDZcqWM6KE6jVBB3ITrm 3nRWl6DNA2l1Wg3iKD8ssh5GvlGOAz9p2c4sgdxT3XYCrfeIlZgyrYbWfrpQRhk6OYlG AA2b6tQo9JE95lp+OG2ZEL3DlhcQNo+kARj5IJrscXBbbus1mVdXVzmS+TDmHTWNkhJ/ t+yKvrkgapjWx6pU6SXI5p/rz7DYFg+lsQrHXBSOyMKXVRsz9v19AYco/Rjg+Uav6jjg EOyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=TEDeTomU; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2-v6si3976255plh.485.2018.08.03.09.38.43; Fri, 03 Aug 2018 09:38:58 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=TEDeTomU; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728412AbeHCSet (ORCPT + 99 others); Fri, 3 Aug 2018 14:34:49 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:42823 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727362AbeHCSet (ORCPT ); Fri, 3 Aug 2018 14:34:49 -0400 Received: by mail-io0-f196.google.com with SMTP id g11-v6so5474745ioq.9; Fri, 03 Aug 2018 09:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NhGHLCuCDrC3t2YKc6PPYC7XNF/mP/dEl9RYiSyhq9E=; b=TEDeTomUMKBUXIvTXNmFyvYFZR2kvUe0HvCNqnCOADTNkq9OYw0atHpabH/PldQ2ie nZ7jLF+mQCmQ8lK62O5MaD+DaKgVx90nP9irfDS2xFV2rR+scvv0TzEaPIgq45BGquMi Rf1o07tVBc86cQ8QiHcE4lcjV5u4wpvl0/3wI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NhGHLCuCDrC3t2YKc6PPYC7XNF/mP/dEl9RYiSyhq9E=; b=beY7r7Im+e1zHpRkTuFtePl7MhOtcDb6Q7EmCkguqa1HoqCoMSKOC0M8VOC0pdqWMl DIuwacth3GsdhMVoG9x3u/xpJn82prUcNCFnBWfmg/5NJSL7urXzE7IlRcaea4aEId9Q nUzgdPiEcfBfB1hF/CWH2Nv5fFfi/r59GWV8ti/syT5kHfaNjZVvBbX9Ryi7K0GqdhcW 2XiMxpYsj5yt5Ko6w9jwIAwP9mSmRMjdbB3cElmetBo5oIOyJkHwjI64Axlu50yp7pbv wpvh+9arL+jR9CLEfGUTMN0Hhe8lktVpAFBHl3bKK9R0ODO292Y8FSKzzkcTWSdxYd7T Ap1g== X-Gm-Message-State: AOUpUlGHSBz2LkJS6BmVz6KT8BSekLO4w816M+7f5HSWLwNG1NvXbUm7 TgkhOw3q0SoV712ycaVbmqjbMZHAsn3hbyoyIEA= X-Received: by 2002:a6b:fc0c:: with SMTP id r12-v6mr7093910ioh.203.1533314266130; Fri, 03 Aug 2018 09:37:46 -0700 (PDT) MIME-Version: 1.0 References: <226835ba-2197-b850-6e5b-8ba14f7fd016@torlan.ru> <93bff248-6897-4867-841b-2dace11597de@torlan.ru> <1ec0a220-d5b0-1c27-e63b-c4d3f4ce9d77@torlan.ru> In-Reply-To: From: Linus Torvalds Date: Fri, 3 Aug 2018 09:37:35 -0700 Message-ID: Subject: Re: LVM snapshot broke between 4.14 and 4.16 To: Zdenek Kabelac Cc: wgh@torlan.ru, Ilya Dryomov , Jens Axboe , linux-block , Linux Kernel Mailing List , Sagi Grimberg , Mike Snitzer , dm-devel@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Dammit. I haven't had to shout and curse at people for a while, but this is ABSOLUTELY THE MOST IMPORTANT THING IN THE UNIVERSE WHEN IT COMES TO SOFTWARE DEVELOPMENT ] On Fri, Aug 3, 2018 at 6:31 AM 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). Yeah, HELL NO! Guess what? You're wrong. YOU ARE MISSING THE #1 KERNEL RULE. We do not regress, and we do not regress exactly because your are 100% wrong. And the reason you state for your opinion is in fact exactly *WHY* you are wrong. Your "good reasons" are pure and utter garbage. The whole point of "we do not regress" is so that people can upgrade the kernel and never have to worry about it. > Kernel had a bug which has been fixed That is *ENTIRELY* immaterial. Guys, whether something was buggy or not DOES NOT MATTER. Why? Bugs happen. That's a fact of life. Arguing that "we had to break something because we were fixing a bug" is completely insane. We fix tens of bugs every single day, thinking that "fixing a bug" means that we can break something is simply NOT TRUE. So bugs simply aren't even relevant to the discussion. They happen, they get found, they get fixed, and it has nothing to do with "we break users". Because the only thing that matters IS THE USER. How hard is that to understand? Anybody who uses "but it was buggy" as an argument is entirely missing the point. As far as the USER was concerned, it wasn't buggy - it worked for him/her. Maybe it worked *because* the user had taken the bug into account, maybe it worked because the user didn't notice - again, it doesn't matter. It worked for the user. Breaking a user workflow for a "bug" is absolutely the WORST reason for breakage you can imagine. It's basically saying "I took something that worked, and I broke it, but now it's better". Do you not see how f*cking insane that statement is? And without users, your program is not a program, it's a pointless piece of code that you might as well throw away. Seriously. This is *why* the #1 rule for kernel development is "we don't break users". Because "I fixed a bug" is absolutely NOT AN ARGUMENT if that bug fix broke a user setup. You actually introduced a MUCH BIGGER bug by "fixing" something that the user clearly didn't even care about. And dammit, we upgrade the kernel ALL THE TIME without upgrading any other programs at all. It is absolutely required, because flag-days and dependencies are horribly bad. And it is also required simply because I as a kernel developer do not upgrade random other tools that I don't even care about as I develop the kernel, and I want any of my users to feel safe doing the same time. So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel without upgrading some other random binary, then we have a problem. Linus