From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
To: linux-ext4@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>
Cc: John Garry <john.g.garry@oracle.com>,
dchinner@redhat.com, "Darrick J . Wong" <djwong@kernel.org>,
Ritesh Harjani <ritesh.list@gmail.com>,
linux-kernel@vger.kernel.org
Subject: [RFC v3 06/11] ext4: make extsize work with EOF allocations
Date: Mon, 24 Mar 2025 13:07:04 +0530 [thread overview]
Message-ID: <c5169040ac2616a0e57df7d09cf2083a86def6ca.1742800203.git.ojaswin@linux.ibm.com> (raw)
In-Reply-To: <cover.1742800203.git.ojaswin@linux.ibm.com>
Make extsize hints work with EOF allocations. We deviate from XFS here
because in case we have blocks left past EOF, we don't truncate them.
There are 2 main reasons:
1. Since the user is opting for extsize allocations, chances are
that they will use the blocks in future.
2. If we start truncating all EOF blocks in ext4_release_file like
XFS, then we will have to always truncate blocks even if they
have been intentionally preallocated using fallocate w/ KEEP_SIZE
which might cause confusion for users. This is mainly because
ext4 doesn't have a way to distinguish if the blocks beyond EOF
have been allocated intentionally. We can work around this by
using an ondisk inode flag like XFS (XFS_DIFLAG_PREALLOC) but
that would be an overkill. It's much simpler to just let the EOF
blocks stick around.
NOTE:
One thing that changes in this patch is that for direct IO we need to
pass the EXT4_GET_BLOCKS_IO_CREATE_EXT even if we are allocating beyond
i_size.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
---
fs/ext4/inode.c | 22 ++++++----------------
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 53724b7cb9e0..bf19b9f99cea 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -757,7 +757,6 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
* ext4_extents.h here?
*/
int max_unwrit_len = ((1UL << 15) - 1);
- loff_t end;
align = orig_map->m_lblk % extsize;
len = orig_map->m_len + align;
@@ -766,18 +765,6 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
extsize_map.m_len =
max_t(unsigned int, roundup_pow_of_two(len), extsize);
- /*
- * For now allocations beyond EOF don't use extsize hints so
- * that we can avoid dealing with extra blocks allocated past
- * EOF. We have inode lock since extsize allocations are
- * non-delalloc so i_size can be accessed safely
- */
- end = (extsize_map.m_lblk + (loff_t)extsize_map.m_len) << inode->i_blkbits;
- if (end > inode->i_size) {
- flags = orig_flags & ~EXT4_GET_BLOCKS_EXTSIZE;
- goto set_map;
- }
-
/* Fallback to normal allocation if we go beyond max len */
if (extsize_map.m_len >= max_unwrit_len) {
flags = orig_flags & ~EXT4_GET_BLOCKS_EXTSIZE;
@@ -3645,10 +3632,13 @@ static int ext4_iomap_alloc(struct inode *inode, struct ext4_map_blocks *map,
* i_disksize out to i_size. This could be beyond where direct I/O is
* happening and thus expose allocated blocks to direct I/O reads.
*
- * NOTE for extsize hints: We only support it for writes inside
- * EOF (for now) to not have to deal with blocks past EOF
+ * NOTE: For extsize hint based EOF allocations, we still need
+ * IO_CREATE_EXT flag because we will be allocating more than the write
+ * hence the extra blocks need to be marked unwritten and split before
+ * the I/O.
*/
- else if (((loff_t)map->m_lblk << blkbits) >= i_size_read(inode))
+ else if (((loff_t)map->m_lblk << blkbits) >= i_size_read(inode) &&
+ !ext4_should_use_extsize(inode))
m_flags = EXT4_GET_BLOCKS_CREATE;
else if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
m_flags = EXT4_GET_BLOCKS_IO_CREATE_EXT;
--
2.48.1
next prev parent reply other threads:[~2025-03-24 7:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 7:36 [RFC v3 00/11] ext4: Add extsize and forcealign support (groundwork for multi block atomic writes) Ojaswin Mujoo
2025-03-24 7:36 ` [RFC v3 01/11] ext4: add aligned allocation hint in mballoc Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 02/11] ext4: allow inode preallocation for aligned alloc Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 03/11] ext4: support for extsize hint using FS_IOC_FS(GET/SET)XATTR Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 04/11] ext4: pass lblk and len explicitly to ext4_split_extent*() Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 05/11] ext4: add extsize hint support Ojaswin Mujoo
2025-03-24 7:37 ` Ojaswin Mujoo [this message]
2025-03-24 7:37 ` [RFC v3 07/11] ext4: add ext4_map_blocks_extsize() wrapper to handle overwrites Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 08/11] ext4: add forcealign support of mballoc Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 09/11] ext4: add forcealign support to ext4_map_blocks Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 10/11] ext4: add support for adding focealign via SETXATTR ioctl Ojaswin Mujoo
2025-03-24 7:37 ` [RFC v3 11/11] ext4: disallow unaligned deallocations on forcealign inodes Ojaswin Mujoo
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=c5169040ac2616a0e57df7d09cf2083a86def6ca.1742800203.git.ojaswin@linux.ibm.com \
--to=ojaswin@linux.ibm.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.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
all inboxes | Powered by JetHome®