From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org,
John Garry <john.g.garry@oracle.com>,
djwong@kernel.org, linux-xfs@vger.kernel.org,
Theodore Ts'o <tytso@mit.edu>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [RFCv1 0/1] EXT4 support of multi-fsblock atomic write with bigalloc
Date: Sun, 23 Mar 2025 12:30:09 +0530 [thread overview]
Message-ID: <cover.1742699765.git.ritesh.list@gmail.com> (raw)
In-Reply-To: <Z5nTaQgLGdD6hSvL@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
This is an RFC patch before LSFMM to preview the change of how multi-fsblock atomic write
support with bigalloc look like. There is a scope of improvement in the
implementation, however this shows the general idea of the design. More details
are provided in the actual patch. There are still todos and more testing is
needed. But with iomap limitation of single fsblock atomic write now lifted,
the patch has definitely started to look better.
This is based out of vfs.all tree [1] for 6.15, which now has the necessary
iomap changes required for the bigalloc support in ext4.
TODOs:
1. Add better testcases to test atomic write support with bigalloc.
2. Discuss the approach of keeping the jbd2 txn open while zeroing the short
underlying unwritten extents or short holes to create a single mapped type
extent mapping. This anyway should be a non-perfomance critical path.
3. We use ext4_map_blocks() in loop instead of modifying the block allocator.
Again since it's non-performance sensitive path, so hopefully it should ok?
Because otherwise one can argue why take and release
EXT4_I(inode)->i_data_sem multiple times. We won't take & release any group
lock for this, since we know that with bigalloc the cluster is anyway
available to us.
4. Once when we start supporting file/inode marked with atomic writes attribute,
maybe we can add some optimizations like zero out the entire underlying
cluster when someone forcefully wants to fzero or fpunch an underlying disk
block, to keep the mapped extent intact.
5. Stress test of this is still pending through fsx and xfstests.
Reviews are appreciated.
[1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.all&id=4f76518956c037517a4e4b120186075d3afb8266
Ritesh Harjani (IBM) (1):
ext4: Add atomic write support for bigalloc
fs/ext4/inode.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++--
fs/ext4/super.c | 8 +++--
2 files changed, 93 insertions(+), 5 deletions(-)
--
2.48.1
WARNING: multiple messages have this Message-ID (diff)
From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org,
John Garry <john.g.garry@oracle.com>,
djwong@kernel.org, linux-xfs@vger.kernel.org,
Theodore Ts'o <tytso@mit.edu>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [RFCv1 0/1] EXT4 support of multi-fsblock atomic write with bigalloc
Date: Sun, 23 Mar 2025 12:32:17 +0530 [thread overview]
Message-ID: <cover.1742699765.git.ritesh.list@gmail.com> (raw)
Message-ID: <20250323070217.jfIhyllRxLF3C3dNCITBOApEXmkZ0mG92Fg6M8Xk2cA@z> (raw)
This is an RFC patch before LSFMM to preview the change of how multi-fsblock atomic write
support with bigalloc look like. There is a scope of improvement in the
implementation, however this shows the general idea of the design. More details
are provided in the actual patch. There are still todos and more testing is
needed. But with iomap limitation of single fsblock atomic write now lifted,
the patch has definitely started to look better.
This is based out of vfs.all tree [1] for 6.15, which now has the necessary
iomap changes required for the bigalloc support in ext4.
TODOs:
1. Add better testcases to test atomic write support with bigalloc.
2. Discuss the approach of keeping the jbd2 txn open while zeroing the short
underlying unwritten extents or short holes to create a single mapped type
extent mapping. This anyway should be a non-perfomance critical path.
3. We use ext4_map_blocks() in loop instead of modifying the block allocator.
Again since it's non-performance sensitive path, so hopefully it should ok?
Because otherwise one can argue why take and release
EXT4_I(inode)->i_data_sem multiple times. We won't take & release any group
lock for this, since we know that with bigalloc the cluster is anyway
available to us.
4. Once when we start supporting file/inode marked with atomic writes attribute,
maybe we can add some optimizations like zero out the entire underlying
cluster when someone forcefully wants to fzero or fpunch an underlying disk
block, to keep the mapped extent intact.
5. Stress test of this is still pending through fsx and xfstests.
Reviews are appreciated.
[1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.all&id=4f76518956c037517a4e4b120186075d3afb8266
Ritesh Harjani (IBM) (1):
ext4: Add atomic write support for bigalloc
fs/ext4/inode.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++--
fs/ext4/super.c | 8 +++--
2 files changed, 93 insertions(+), 5 deletions(-)
--
2.48.1
next prev parent reply other threads:[~2025-03-23 7:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 7:06 [LSF/MM/BPF TOPIC] extsize and forcealign design in filesystems for atomic writes Ojaswin Mujoo
2025-01-29 8:59 ` John Garry
2025-01-29 16:06 ` Ojaswin Mujoo
2025-01-30 14:08 ` John Garry
2025-02-01 7:12 ` Ojaswin Mujoo
2025-02-04 12:20 ` John Garry
2025-02-04 20:12 ` Dave Chinner
2025-02-07 6:08 ` Ojaswin Mujoo
2025-02-07 12:01 ` John Garry
2025-02-08 17:05 ` Ojaswin Mujoo
2025-03-23 7:00 ` Ritesh Harjani (IBM) [this message]
2025-03-23 7:00 ` [RFCv1 1/1] ext4: Add multi-fsblock atomic write support with bigalloc Ritesh Harjani (IBM)
2025-03-23 7:02 ` Ritesh Harjani (IBM)
2025-03-25 11:42 ` Ojaswin Mujoo
2025-03-23 7:02 ` [RFCv1 0/1] EXT4 support of multi-fsblock atomic write " Ritesh Harjani (IBM)
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.1742699765.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=djwong@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@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;
as well as URLs for NNTP newsgroup(s).