All of
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Zdenek Kabelac <>
Cc:, Ilya Dryomov <>,
	Jens Axboe <>,
	linux-block <>,
	Linux Kernel Mailing List <>,
	Sagi Grimberg <>,
	Mike Snitzer <>,
Subject: Re: LVM snapshot broke between 4.14 and 4.16
Date: Fri, 3 Aug 2018 09:37:35 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[ Dammit. I haven't had to shout and curse at people for a while, but

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.


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

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

So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
without upgrading some other random binary, then we have a problem.


  reply	other threads:[~2018-08-03 16:37 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
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 [this message]
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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \

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