From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>
Cc: John Garry <john.g.garry@oracle.com>,
djwong@kernel.org, Ojaswin Mujoo <ojaswin@linux.ibm.com>,
linux-ext4@vger.kernel.org,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc
Date: Wed, 30 Apr 2025 10:50:40 +0530 [thread overview]
Message-ID: <cover.1745987268.git.ritesh.list@gmail.com> (raw)
This is still an early preview (RFC v2) of multi-fsblock atomic write. Since the
core design of the feature looks ready, wanted to post this for some early
feedback. We will break this into more smaller and meaningful patches in later
revision. However to simplify the review of the core design changes, this
version is limited to just two patches. Individual patches might have more
details in the commit msg.
Note: This overall needs more careful review (other than the core design) which
I will be doing in parallel. However it would be helpful if one can provide any
feedback on the core design changes. Specially around ext4_iomap_alloc()
changes, ->end_io() changes and a new get block flag
EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS.
v1 -> v2:
==========
1. Handled review comments from Ojaswin to optimize the ext4_map_block() calls
in ext4_iomap_alloc().
2. Fixed the journal credits calculation for both:
- during block allocation in ext4_iomap_alloc()
- during dio completion in ->end_io callback.
Earlier we were starting multiple txns in ->end_io callback for unwritten to
written conversion. But since in case of atomic writes, we want a single jbd2
txn, hence made the necessary changes there.
TODOs:
======
1. although this survived quick tests and some custom fio tests for atomic
write, but I still think we need to add more tests for the corner cases.
Will work on adding such corner test cases to xfstests.
2. Many fsx related tests in quick group were failing with bigalloc. But those
were failing even without these patches. Need further investigation.
3. Finish more thorough testing of the series.
4. Refactoring + Cleanups and a more careful review of the overall patch series
before sending v3.
Ritesh Harjani (IBM) (2):
ext4: Add multi-fsblock atomic write support with bigalloc
ext4: Add support for EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS
fs/ext4/ext4.h | 9 ++
fs/ext4/extents.c | 69 ++++++++++++++
fs/ext4/file.c | 7 +-
fs/ext4/inode.c | 231 ++++++++++++++++++++++++++++++++++++++++++----
fs/ext4/super.c | 8 +-
5 files changed, 302 insertions(+), 22 deletions(-)
--
2.49.0
next reply other threads:[~2025-04-30 5:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 5:20 Ritesh Harjani (IBM) [this message]
2025-04-30 5:20 ` [RFC v2 1/2] ext4: Add multi-fsblock atomic write support with bigalloc Ritesh Harjani (IBM)
2025-04-30 5:20 ` [RFC v2 2/2] ext4: Add support for EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS Ritesh Harjani (IBM)
2025-05-08 12:01 ` [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc John Garry
2025-05-08 14:35 ` Ritesh Harjani
2025-05-08 15:19 ` Darrick J. Wong
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=cover.1745987268.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=john.g.garry@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=tytso@mit.edu \
/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