From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Yongpeng Yang <monty_pavel@sina.com>
Cc: Yongpeng Yang <yangyongpeng@xiaomi.com>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 3/4] f2fs: fix fiemap boundary handling when read extent cache is incomplete
Date: Tue, 24 Feb 2026 03:48:44 +0000 [thread overview]
Message-ID: <aZ0fnM-sJqRTt6v5@google.com> (raw)
In-Reply-To: <20260203133635.3942502-5-monty_pavel@sina.com>
On 02/03, Yongpeng Yang wrote:
> From: Yongpeng Yang <yangyongpeng@xiaomi.com>
>
> f2fs_fiemap() calls f2fs_map_blocks() to obtain the block mapping a
> file, and then merges contiguous mappings into extents. If the mapping
> is found in the read extent cache, node blocks do not need to be read.
> However, in the following scenario, a contiguous extent can be split
> into two extents:
>
> root@vm:/mnt/f2fs# dd if=/dev/zero of=data.4M bs=1M count=4 && sync
> root@vm:/mnt/f2fs# dd if=/dev/zero of=data.4M bs=1M count=2 seek=2 conv=notrunc && sync
> root@vm:/mnt/f2fs# echo 3 > /proc/sys/vm/drop_caches # drop 2M~4M extent cache
> root@vm:/mnt/f2fs# dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync
> root@vm:/mnt/f2fs# f2fs_io fiemap 0 1024 data.4M
> Fiemap: offset = 0 len = 1024
> logical addr. physical addr. length flags
> 0 0000000000000000 0000000006400000 0000000000200000 00001000
> 1 0000000000200000 0000000006600000 0000000000200000 00001001
>
> Although the physical addresses of the ranges 0~2MB and 2M~4MB are
> contiguous, the mapping for the 2M~4MB range is not present in memory.
> When the physical addresses for the 0~2MB range are updated, no merge
> happens because the adjacent mapping is missing from the in-memory
> cache. As a result, fiemap reports two separate extents instead of a
> single contiguous one.
>
> The root cause is that the read extent cache does not guarantee that all
> blocks of an extent are present in memory. Therefore, when the extent
> length returned by f2fs_map_blocks_cached() is smaller than maxblocks,
> the remaining mappings are retrieved via f2fs_get_dnode_of_data() to
> ensure correct fiemap extent boundary handling.
>
> Fixes: cd8fc5226bef ("f2fs: remove the create argument to f2fs_map_blocks")
> Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
> ---
> fs/f2fs/data.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 42f15fd9c68e..eedadccf86bb 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1623,8 +1623,18 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, int flag)
> lfs_dio_write = (flag == F2FS_GET_BLOCK_DIO && f2fs_lfs_mode(sbi) &&
> map->m_may_create);
>
> - if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag))
> - goto out;
> + if (!map->m_may_create) {
> + if (f2fs_map_blocks_cached(inode, map, flag)) {
> + if (map->m_len == maxblocks)
> + goto out;
> + else {
> + pgofs = (pgoff_t)map->m_lblk + map->m_len;
> + end = map->m_lblk + maxblocks;
> + ofs = map->m_len;
> + goto next_dnode;
> + }
> + }
> + }
Cleaned up as below:
- if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag))
- goto out;
+ if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag)) {
+ if (map->m_len == maxblocks)
+ goto out;
+
+ pgofs = (pgoff_t)map->m_lblk + map->m_len;
+ end = map->m_lblk + maxblocks;
+ ofs = map->m_len;
+ goto next_dnode;
+ }
>
> map->m_bdev = inode->i_sb->s_bdev;
> map->m_multidev_dio =
> --
> 2.43.0
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2026-02-24 6:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 13:36 [f2fs-dev] [PATCH 1/4] f2fs: fix incorrect extent flag when physical addr is NEW_ADDR in f2fs_fiemap Yongpeng Yang
2026-02-03 13:36 ` [f2fs-dev] [PATCH 2/4] f2fs: fix incorrect file address mapping when inline inode is unwritten Yongpeng Yang
2026-03-04 9:14 ` Chao Yu via Linux-f2fs-devel
2026-02-03 13:36 ` [f2fs-dev] [PATCH 3/4] f2fs: fix fiemap boundary handling when read extent cache is incomplete Yongpeng Yang
2026-02-24 3:48 ` Jaegeuk Kim via Linux-f2fs-devel [this message]
2026-02-24 4:38 ` Jaegeuk Kim via Linux-f2fs-devel
2026-02-27 7:44 ` Yongpeng Yang
2026-02-27 19:23 ` Jaegeuk Kim via Linux-f2fs-devel
2026-02-27 20:41 ` Jaegeuk Kim via Linux-f2fs-devel
2026-03-06 9:15 ` Yongpeng Yang
2026-03-19 3:38 ` Yongpeng Yang
2026-02-03 13:37 ` [f2fs-dev] [PATCH 4/4] f2fs: fix inline data not being written to disk in writeback path Yongpeng Yang
2026-03-04 9:30 ` Chao Yu via Linux-f2fs-devel
2026-03-06 8:55 ` Yongpeng Yang
2026-03-04 9:13 ` [f2fs-dev] [PATCH 1/4] f2fs: fix incorrect extent flag when physical addr is NEW_ADDR in f2fs_fiemap Chao Yu via Linux-f2fs-devel
2026-03-06 9:18 ` Yongpeng Yang
2026-03-05 19:10 ` patchwork-bot+f2fs--- via Linux-f2fs-devel
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=aZ0fnM-sJqRTt6v5@google.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=jaegeuk@kernel.org \
--cc=monty_pavel@sina.com \
--cc=yangyongpeng@xiaomi.com \
/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