From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
To: linux-ext4@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>
Cc: Ritesh Harjani <ritesh.list@gmail.com>,
linux-kernel@vger.kernel.org,
"Darrick J . Wong" <djwong@kernel.org>,
linux-fsdevel@vger.kernel.org,
John Garry <john.g.garry@oracle.com>,
dchinner@redhat.com, Nirjhar Roy <nirjhar@linux.ibm.com>
Subject: [RFC v2 6/6] ext4: make extsize work with EOF allocations
Date: Wed, 11 Dec 2024 13:27:55 +0530 [thread overview]
Message-ID: <57264a45aabcf8d789278e09da5db297d2e6b192.1733901374.git.ojaswin@linux.ibm.com> (raw)
In-Reply-To: <cover.1733901374.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 d511282ebdcc..d292e39a050a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -756,7 +756,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;
@@ -765,18 +764,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;
@@ -3641,10 +3628,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.43.5
prev parent reply other threads:[~2024-12-11 7:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 7:57 [RFC v2 0/6] ext4: Implement support for extsize hints Ojaswin Mujoo
2024-12-11 7:57 ` [RFC v2 1/6] ext4: add aligned allocation hint in mballoc Ojaswin Mujoo
2024-12-11 7:57 ` [RFC v2 2/6] ext4: allow inode preallocation for aligned alloc Ojaswin Mujoo
2024-12-11 7:57 ` [RFC v2 3/6] ext4: support for extsize hint using FS_IOC_FS(GET/SET)XATTR Ojaswin Mujoo
2024-12-11 7:57 ` [RFC v2 4/6] ext4: pass lblk and len explicitly to ext4_split_extent*() Ojaswin Mujoo
2024-12-11 7:57 ` [RFC v2 5/6] ext4: add extsize hint support Ojaswin Mujoo
2024-12-11 7:57 ` Ojaswin Mujoo [this message]
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=57264a45aabcf8d789278e09da5db297d2e6b192.1733901374.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-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nirjhar@linux.ibm.com \
--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®