From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: stop iterating f2fs_map_block if hole exists
Date: Mon, 9 Oct 2023 10:56:41 -0700 [thread overview]
Message-ID: <ZSQ-2aH7qN_ILfEg@google.com> (raw)
In-Reply-To: <c70b330a-b5f5-72d9-1190-fe1a6872919d@kernel.org>
On 10/07, Chao Yu wrote:
> On 2023/10/4 6:52, Jaegeuk Kim wrote:
> > Let's avoid unnecessary f2fs_map_block calls to load extents.
> >
> > # f2fs_io fadvise willneed 0 4096 /data/local/tmp/test
> >
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 386, start blkaddr = 0x34ac00, len = 0x1400, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 5506, start blkaddr = 0x34c200, len = 0x1000, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 9602, start blkaddr = 0x34d600, len = 0x1200, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 14210, start blkaddr = 0x34ec00, len = 0x400, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 15235, start blkaddr = 0x34f401, len = 0xbff, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 18306, start blkaddr = 0x350200, len = 0x1200, flags = 2
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 22915, start blkaddr = 0x351601, len = 0xa7d, flags = 2
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 25600, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 25601, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 25602, start blkaddr = 0x351601, len = 0x0, flags = 0
> > ...
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 1037188, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 1038206, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 1039224, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 2075548, start blkaddr = 0x351601, len = 0x0, flags = 0
>
> Jaegeuk,
>
> Not sure, but it looks it's due to f2fs_precache_extents() will traverse file
> w/ range [0, max_file_blocks), since data which exceeds EOF will always be zero,
> so it's not necessary to precache its mapping info, so we'd better adjust upper
> boundary to i_size rather than max_file_blocks().
>
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> > fs/f2fs/file.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 161826c6e200..2403fd1de5a0 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -3270,7 +3270,7 @@ int f2fs_precache_extents(struct inode *inode)
> > f2fs_down_write(&fi->i_gc_rwsem[WRITE]);
> > err = f2fs_map_blocks(inode, &map, F2FS_GET_BLOCK_PRECACHE);
> > f2fs_up_write(&fi->i_gc_rwsem[WRITE]);
> > - if (err)
> > + if (err || !map.m_len)
> Well, if there is a hole in the head of file, it may break here rather
> than precaching following valid map info.
>
> What about passing parameter offset|len from f2fs_file_fadvise() to
> f2fs_precache_extents(), and then precaching mapping info on demand.
I'd rather stop reading metadata if it meets a hole within i_size, since this
gives benefits when reading the entire non-hole case, FWIW. Rather than that,
I think generic readahead flow can hide the metadata loading.
>
> Thanks,
>
> > return err;
> > map.m_lblk = m_next_extent;
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: stop iterating f2fs_map_block if hole exists
Date: Mon, 9 Oct 2023 10:56:41 -0700 [thread overview]
Message-ID: <ZSQ-2aH7qN_ILfEg@google.com> (raw)
In-Reply-To: <c70b330a-b5f5-72d9-1190-fe1a6872919d@kernel.org>
On 10/07, Chao Yu wrote:
> On 2023/10/4 6:52, Jaegeuk Kim wrote:
> > Let's avoid unnecessary f2fs_map_block calls to load extents.
> >
> > # f2fs_io fadvise willneed 0 4096 /data/local/tmp/test
> >
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 386, start blkaddr = 0x34ac00, len = 0x1400, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 5506, start blkaddr = 0x34c200, len = 0x1000, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 9602, start blkaddr = 0x34d600, len = 0x1200, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 14210, start blkaddr = 0x34ec00, len = 0x400, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 15235, start blkaddr = 0x34f401, len = 0xbff, flags = 2,
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 18306, start blkaddr = 0x350200, len = 0x1200, flags = 2
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 22915, start blkaddr = 0x351601, len = 0xa7d, flags = 2
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 25600, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 25601, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 25602, start blkaddr = 0x351601, len = 0x0, flags = 0
> > ...
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 1037188, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 1038206, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 1039224, start blkaddr = 0x351601, len = 0x0, flags = 0
> > f2fs_map_blocks: dev = (254,51), ino = 85845, file offset = 2075548, start blkaddr = 0x351601, len = 0x0, flags = 0
>
> Jaegeuk,
>
> Not sure, but it looks it's due to f2fs_precache_extents() will traverse file
> w/ range [0, max_file_blocks), since data which exceeds EOF will always be zero,
> so it's not necessary to precache its mapping info, so we'd better adjust upper
> boundary to i_size rather than max_file_blocks().
>
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> > fs/f2fs/file.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 161826c6e200..2403fd1de5a0 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -3270,7 +3270,7 @@ int f2fs_precache_extents(struct inode *inode)
> > f2fs_down_write(&fi->i_gc_rwsem[WRITE]);
> > err = f2fs_map_blocks(inode, &map, F2FS_GET_BLOCK_PRECACHE);
> > f2fs_up_write(&fi->i_gc_rwsem[WRITE]);
> > - if (err)
> > + if (err || !map.m_len)
> Well, if there is a hole in the head of file, it may break here rather
> than precaching following valid map info.
>
> What about passing parameter offset|len from f2fs_file_fadvise() to
> f2fs_precache_extents(), and then precaching mapping info on demand.
I'd rather stop reading metadata if it meets a hole within i_size, since this
gives benefits when reading the entire non-hole case, FWIW. Rather than that,
I think generic readahead flow can hide the metadata loading.
>
> Thanks,
>
> > return err;
> > map.m_lblk = m_next_extent;
next prev parent reply other threads:[~2023-10-09 17:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 22:52 [f2fs-dev] [PATCH] f2fs: stop iterating f2fs_map_block if hole exists Jaegeuk Kim
2023-10-03 22:52 ` Jaegeuk Kim
2023-10-07 7:40 ` [f2fs-dev] " Chao Yu
2023-10-07 7:40 ` Chao Yu
2023-10-09 17:56 ` Jaegeuk Kim [this message]
2023-10-09 17:56 ` Jaegeuk Kim
2023-10-23 15:30 ` patchwork-bot+f2fs
2023-10-23 15:30 ` 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=ZSQ-2aH7qN_ILfEg@google.com \
--to=jaegeuk@kernel.org \
--cc=chao@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.