From: Seongjae Jeong <jsjlee1020@gmail.com>
To: jaegeuk@kernel.org, chao@kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
Seongjae Jeong <jsjlee1020@gmail.com>
Subject: [PATCH] f2fs: skip node_change lock for inline data writes
Date: Sun, 6 Sep 2026 14:56:11 +0000 [thread overview]
Message-ID: <20260906145614.2749-1-jsjlee1020@gmail.com> (raw)
The node_change lock serializes block reservation in the PRE_AIO path
against checkpoint preparation, since block reservation can create
dirty node pages and update checkpoint accounting.
However, writes that remain within the inline data area return before
the block reservation path. Thus, they do not call
inc_valid_block_count(), change a node mapping from NULL_ADDR to
NEW_ADDR, or create a dirty node page as a result of block reservation.
They also do not update total_valid_block_count or
alloc_valid_block_count.
The inline path only copies the existing inline data to the data folio,
sets FI_DATA_EXIST, and marks the inode folio for deferred inline data
flushing. FI_DATA_EXIST can dirty inode metadata, but it does not
reserve a block or update the node mapping and checkpoint accounting
that node_change is intended to serialize.
Skip f2fs_map_lock() for writes that fit within MAX_INLINE_DATA. Keep
the existing locking for inline conversion, which can update filesystem
metadata and requires checkpoint serialization.
Signed-off-by: Seongjae Jeong <jsjlee1020@gmail.com>
---
fs/f2fs/data.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 21f396ebe22c..f2fb5ef3cb7a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3690,10 +3690,11 @@ static int prepare_write_begin(struct f2fs_sb_info *sbi,
/* f2fs_lock_op avoids race between write CP and convert_inline_page */
if (f2fs_has_inline_data(inode)) {
- if (pos + len > MAX_INLINE_DATA(inode))
+ if (pos + len > MAX_INLINE_DATA(inode)) {
flag = F2FS_GET_BLOCK_DEFAULT;
- f2fs_map_lock(sbi, &lc, flag);
- locked = true;
+ f2fs_map_lock(sbi, &lc, flag);
+ locked = true;
+ }
} else if ((pos & PAGE_MASK) >= i_size_read(inode)) {
f2fs_map_lock(sbi, &lc, flag);
locked = true;
--
2.53.0
next reply other threads:[~2026-09-06 14:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 14:56 Seongjae Jeong [this message]
2026-09-09 12:24 ` Chao Yu
2026-09-14 15:30 ` [f2fs-dev] " patchwork-bot+f2fs
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=20260906145614.2749-1-jsjlee1020@gmail.com \
--to=jsjlee1020@gmail.com \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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®