From: Sam Edwards <cfsworks@gmail.com>
To: Xiubo Li <xiubli@redhat.com>, Ilya Dryomov <idryomov@gmail.com>
Cc: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>,
Christian Brauner <brauner@kernel.org>,
Milind Changire <mchangir@redhat.com>,
Jeff Layton <jlayton@kernel.org>,
ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
Sam Edwards <CFSworks@gmail.com>
Subject: [PATCH v3 0/4] ceph: CephFS writeback correctness and performance fixes
Date: Sun, 25 Jan 2026 18:30:51 -0800 [thread overview]
Message-ID: <20260126023055.405401-1-CFSworks@gmail.com> (raw)
Hello list,
This is v2 of my series that addresses interrelated issues in CephFS writeback,
fixing crashes, improving robustness, and correcting performance behavior,
particularly for fscrypted files. [1]
Changes v2->v3:
- Split out two patches ("ceph: free page array when ceph_submit_write() fails"
and "ceph: split out page-array discarding to a function") to a new series
[2] since they are independent and had no outstanding review comments.
- Lowercase the subject lines of commit messages, per subsystem-local style.
- Update the commit message of ("ceph: fix write storm on fscrypted files") to
mention the explicit dependency on ("ceph: do not propagate page array
emplacement errors as batch errors") for correctness, to prevent the former
from being accidentally backported without the latter.
- Reorder the series to make the aforementioned patches consecutive. The series
cadence is now: bugfix, bugfix, cleanup, cleanup
- Add a clarification to ("ceph: remove error return from
ceph_process_folio_batch()") that "abort" logic is still possible, just that
it is responsible for cleaning up after itself.
Changes v1->v2:
- Clarify patch #1's commit message to establish that failures on the first
folio are not possible.
- Add another patch to move the "clean up page array on abort" logic to a new
ceph_discard_page_array() function. (Thanks Slava!)
- Change the wording "grossly degraded performance" to instead read
"correspondingly degraded performance." This makes the causal relationship
clearer (that write throughput is limited much more significantly by write
op/s due to the bug) without making any claims (qualitative or otherwise)
about significance. (Thanks Slava!)
- Reset locked_pages = 0 immediately when the page array is discarded,
simplifying patch #5 ("ceph: Assert writeback loop invariants")
- Reword "as evidenced by the previous two patches which fix oopses" to
"as evidenced by two recent patches which fix oopses" and refer to the
patches by subject (being in the same series, I cannot refer to them by hash)
Warm regards,
Sam
[1] https://lore.kernel.org/all/20260107210139.40554-1-CFSworks@gmail.com/
[2] https://lore.kernel.org/all/20260126022715.404984-1-CFSworks@gmail.com/
Sam Edwards (4):
ceph: do not propagate page array emplacement errors as batch errors
ceph: fix write storm on fscrypted files
ceph: remove error return from ceph_process_folio_batch()
ceph: assert writeback loop invariants
fs/ceph/addr.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--
2.52.0
next reply other threads:[~2026-01-26 2:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 2:30 Sam Edwards [this message]
2026-01-26 2:30 ` [PATCH v3 1/4] ceph: do not propagate page array emplacement errors as batch errors Sam Edwards
2026-01-26 2:30 ` [PATCH v3 2/4] ceph: fix write storm on fscrypted files Sam Edwards
2026-01-26 2:30 ` [PATCH v3 3/4] ceph: remove error return from ceph_process_folio_batch() Sam Edwards
2026-01-26 22:55 ` Viacheslav Dubeyko
2026-01-29 0:29 ` Sam Edwards
2026-02-11 17:55 ` Ilya Dryomov
2026-01-26 2:30 ` [PATCH v3 4/4] ceph: assert writeback loop invariants Sam Edwards
2026-01-26 22:54 ` Viacheslav Dubeyko
2026-01-29 0:14 ` Sam Edwards
2026-02-11 18:04 ` Ilya Dryomov
2026-02-11 18:11 ` [PATCH v3 0/4] ceph: CephFS writeback correctness and performance fixes Ilya Dryomov
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=20260126023055.405401-1-CFSworks@gmail.com \
--to=cfsworks@gmail.com \
--cc=Slava.Dubeyko@ibm.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchangir@redhat.com \
--cc=xiubli@redhat.com \
/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