linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Max Kellermann <max@blarg.de>
To: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Cc: "brauner@kernel.org" <brauner@kernel.org>,
	Patrick Donnelly <pdonnell@redhat.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"slava@dubeyko.com" <slava@dubeyko.com>,
	David Howells <dhowells@redhat.com>,
	Alex Markuze <amarkuze@redhat.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"idryomov@gmail.com" <idryomov@gmail.com>
Subject: Re: [RFC PATCH 3/4] ceph: introduce ceph_submit_write() method
Date: Wed, 27 Aug 2025 00:53:49 +0200	[thread overview]
Message-ID: <aK46_c261i65FZ2f@swift.blarg.de> (raw)
In-Reply-To: <c2b5eafc60e753cba2f7ffe88941f10d65cefa64.camel@ibm.com>

On 2025/08/27 00:33, Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> wrote:
> Of course, we can revert any patch. This patchset has been sent not with the
> goal of pure refactoring but it fixes several bugs. Reverting means returning
> these bugs back.

You should have listened of Matthew and submit separate minimal
bug-fixing patches instead of posting huge patches which move code
around, change semantics and hidden somewhere deep within fix some bug
(and then introduce new bugs).

> This patchset was available for review for a long time.

There was exactly one review, and no, you were not "happy to rework
and to make any patch more better" - you openly rejected Matthew's
review.

> From my point of view, reverting is not answer and it makes sense to
> continue fix bugs and to make CephFS code more stable.

Your argument only appears to sound right, but it is detached from the
reality I'm living in.

Your patches made Ceph less stable.  6.14 had one Ceph-related crash
every other week, but 6.15 with your patches made all servers crash
within hours.

The point is: the Linux kernel was better without your patches.  Your
patches may have fixed a bug, but have introduced a dozen new bugs,
including one that very quickly crashes the whole kernel, one that was
really obvious enough, just nobody cared enough to read deeply enough
after you rejected Matthew's review.  Too bad no maintainer stopped
you!

Of course, the bug that was fixed by your patch set should be fixed -
but not the way you did it.  Every aspect of your approach to fixing
the bug was bad.

The best way forward for you would be to revert this patch set and
write a minimal patch that only fixes the bug.  If you want to be
helpful here, please give this a try.

Max

  reply	other threads:[~2025-08-26 22:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05  0:02 [RFC PATCH 0/4] ceph: fix generic/421 test failure Viacheslav Dubeyko
2025-02-05  0:02 ` [RFC PATCH 1/4] ceph: extend ceph_writeback_ctl for ceph_writepages_start() refactoring Viacheslav Dubeyko
2025-02-05  0:02 ` [RFC PATCH 2/4] ceph: introduce ceph_process_folio_batch() method Viacheslav Dubeyko
2025-02-05  0:02 ` [RFC PATCH 3/4] ceph: introduce ceph_submit_write() method Viacheslav Dubeyko
2025-02-14 21:11   ` Matthew Wilcox
2025-02-14 21:21     ` Viacheslav Dubeyko
2025-08-26 22:06     ` Max Kellermann
2025-08-26 22:33       ` Viacheslav Dubeyko
2025-08-26 22:53         ` Max Kellermann [this message]
2025-08-27  3:06           ` Viacheslav Dubeyko
2025-08-27  4:57             ` Max Kellermann
2025-02-05  0:02 ` [RFC PATCH 4/4] ceph: fix generic/421 test failure Viacheslav Dubeyko
2025-02-12 18:05 ` [RFC PATCH 0/4] " Viacheslav Dubeyko
2025-02-14 17:19 ` David Howells
2025-02-14 17:36   ` Viacheslav Dubeyko
2025-02-14 20:35   ` David Howells
2025-02-14 20:45     ` Viacheslav Dubeyko
2025-02-14 20:52     ` David Howells
2025-02-14 20:57       ` Viacheslav Dubeyko
2025-02-14 23:52       ` Viacheslav Dubeyko
2025-02-28 10:22 ` Christian Brauner

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=aK46_c261i65FZ2f@swift.blarg.de \
    --to=max@blarg.de \
    --cc=Slava.Dubeyko@ibm.com \
    --cc=amarkuze@redhat.com \
    --cc=brauner@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pdonnell@redhat.com \
    --cc=slava@dubeyko.com \
    --cc=willy@infradead.org \
    /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).