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

On Wed, 2025-08-27 at 00:53 +0200, Max Kellermann wrote:
> 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.
> 
> 

This patchset had been tested by xfstests and no issue had been triggered. We
have not enough Ceph related test-cases. So, you are welcome to add a test-case
for the issue.

This issue had been reported more than a month ago. I tried to reproduce it but
I had no luck. So, if you are lucky enough, then simply share the patch or the
way to reproduce the issue. The patchset simply placed old code into dedicated
functions with the goal to manage complexity. So, the old code is still there
and the patch cannot introduce "dozen new bugs". Otherwise, xfstests can easily
reproduce these gazilion of bugs. :) Currently, we have only one issue reported.

The open-source is space for collaboration and respect of each other. It is not
space for offensive or bullying behavior.

Thanks,
Slava.

  reply	other threads:[~2025-08-27  3:07 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
2025-08-27  3:06           ` Viacheslav Dubeyko [this message]
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=4a75d243b3002ae8608b6e2530452924d192524f.camel@ibm.com \
    --to=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).