From: Chao Yu <chao@kernel.org>
To: Sunmin Jeong <s_min.jeong@samsung.com>, jaegeuk@kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net, daehojeong@google.com,
stable@vger.kernel.org, 'Sungjong Seo' <sj1557.seo@samsung.com>,
'Yeongjin Gil' <youngjin.gil@samsung.com>
Subject: Re: [PATCH 1/2] f2fs: use meta inode for GC of atomic file
Date: Fri, 5 Jul 2024 11:31:36 +0800 [thread overview]
Message-ID: <b8db6396-3f44-4a58-a4ef-c413c4a1ea1b@kernel.org> (raw)
In-Reply-To: <000001dace8a$f97d2d30$ec778790$@samsung.com>
On 2024/7/5 11:25, Sunmin Jeong wrote:
> Hi Chao Yu,
>
>>> The page cache of the atomic file keeps new data pages which will be
>>> stored in the COW file. It can also keep old data pages when GCing the
>>> atomic file. In this case, new data can be overwritten by old data if
>>> a GC thread sets the old data page as dirty after new data page was
>>> evicted.
>>>
>>> Also, since all writes to the atomic file are redirected to COW
>>> inodes, GC for the atomic file is not working well as below.
>>>
>>> f2fs_gc(gc_type=FG_GC)
>>> - select A as a victim segment
>>> do_garbage_collect
>>> - iget atomic file's inode for block B
>>> move_data_page
>>> f2fs_do_write_data_page
>>> - use dn of cow inode
>>> - set fio->old_blkaddr from cow inode
>>> - seg_freed is 0 since block B is still valid
>>> - goto gc_more and A is selected as victim again
>>>
>>> To solve the problem, let's separate GC writes and updates in the
>>> atomic file by using the meta inode for GC writes.
>>>
>>> Fixes: 3db1de0e582c ("f2fs: change the current atomic write way")
>>> Cc: stable@vger.kernel.org #v5.19+
>>> Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
>>> Reviewed-by: Yeongjin Gil <youngjin.gil@samsung.com>
>>> Signed-off-by: Sunmin Jeong <s_min.jeong@samsung.com>
>>> ---
>>> fs/f2fs/f2fs.h | 5 +++++
>>> fs/f2fs/gc.c | 6 +++---
>>> fs/f2fs/segment.c | 4 ++--
>>> 3 files changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index
>>> a000cb024dbe..59c5117e54b1 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -4267,6 +4267,11 @@ static inline bool f2fs_post_read_required(struct
>> inode *inode)
>>> f2fs_compressed_file(inode);
>>> }
>>>
>>> +static inline bool f2fs_meta_inode_gc_required(struct inode *inode) {
>>> + return f2fs_post_read_required(inode) || f2fs_is_atomic_file(inode);
>>> +}
>>> +
>>> /*
>>> * compress.c
>>> */
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index
>>> a079eebfb080..136b9e8180a3 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -1580,7 +1580,7 @@ static int gc_data_segment(struct f2fs_sb_info *sbi,
>> struct f2fs_summary *sum,
>>> start_bidx = f2fs_start_bidx_of_node(nofs, inode) +
>>> ofs_in_node;
>>>
>>> - if (f2fs_post_read_required(inode)) {
>>> + if (f2fs_meta_inode_gc_required(inode)) {
>>> int err = ra_data_block(inode, start_bidx);
>>>
>>> f2fs_up_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
>>> @@ -1631,7 +1631,7 @@ static int gc_data_segment(struct f2fs_sb_info
>>> *sbi, struct f2fs_summary *sum,
>>>
>>> start_bidx = f2fs_start_bidx_of_node(nofs, inode)
>>> + ofs_in_node;
>>> - if (f2fs_post_read_required(inode))
>>> + if (f2fs_meta_inode_gc_required(inode))
>>> err = move_data_block(inode, start_bidx,
>>> gc_type, segno, off);
>>> else
>>> @@ -1639,7 +1639,7 @@ static int gc_data_segment(struct f2fs_sb_info *sbi,
>> struct f2fs_summary *sum,
>>> segno, off);
>>>
>>> if (!err && (gc_type == FG_GC ||
>>> - f2fs_post_read_required(inode)))
>>> + f2fs_meta_inode_gc_required(inode)))
>>> submitted++;
>>>
>>> if (locked) {
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index
>>> 7e47b8054413..b55fc4bd416a 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -3823,7 +3823,7 @@ void f2fs_wait_on_block_writeback(struct inode
>> *inode, block_t blkaddr)
>>> struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>>> struct page *cpage;
>>>
>>> - if (!f2fs_post_read_required(inode))
>>> + if (!f2fs_meta_inode_gc_required(inode))
>>> return;
>>>
>>> if (!__is_valid_data_blkaddr(blkaddr))
>>> @@ -3842,7 +3842,7 @@ void f2fs_wait_on_block_writeback_range(struct
>> inode *inode, block_t blkaddr,
>>> struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>>> block_t i;
>>>
>>> - if (!f2fs_post_read_required(inode))
>>> + if (!f2fs_meta_inode_gc_required(inode))
>>> return;
>>>
>>> for (i = 0; i < len; i++)
>>
>> f2fs_write_single_data_page()
>> ...
>> .post_read = f2fs_post_read_required(inode) ? 1 : 0,
>>
>> Do we need to use f2fs_meta_inode_gc_required() here?
>>
>> Thanks,
>
> As you said, we need to use f2fs_meta_inode_gc_required instead of
> f2fs_post_read_required. Then what about changing the variable name
> "post_read" to another one such as "meta_gc"?
Sunmin, yes, I think so.
Thanks,
> struct f2fs_io_info {
> unsigned int post_read:1; /* require post read */
>
> Thanks,
>
next prev parent reply other threads:[~2024-07-05 3:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240702120631epcas1p1c7044f77b56009471e2dc07d4e135a99@epcas1p1.samsung.com>
2024-07-02 12:06 ` [PATCH 1/2] f2fs: use meta inode for GC of atomic file Sunmin Jeong
2024-07-04 7:29 ` Chao Yu
2024-07-05 3:25 ` Sunmin Jeong
2024-07-05 3:31 ` Chao Yu [this message]
[not found] <CGME20240702120051epcas1p35f2ff6260c1b8a768f07ced5413377b6@epcas1p3.samsung.com>
2024-07-02 12:00 ` Sunmin Jeong
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=b8db6396-3f44-4a58-a4ef-c413c4a1ea1b@kernel.org \
--to=chao@kernel.org \
--cc=daehojeong@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=s_min.jeong@samsung.com \
--cc=sj1557.seo@samsung.com \
--cc=stable@vger.kernel.org \
--cc=youngjin.gil@samsung.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