From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/3] f2fs: remove unsafe bitmap checking
Date: Fri, 24 Feb 2017 09:45:41 -0800 [thread overview]
Message-ID: <20170224174541.GA39009@jaegeuk.local> (raw)
In-Reply-To: <9b4cf979-75be-752d-775c-9f76f00d5788@huawei.com>
On 02/24, Chao Yu wrote:
> On 2017/2/23 17:18, Hou Pengyang wrote:
> > proc A: proc B:
> > - writeback_sb_inodes
> > - __writeback_single_inode
> > - do_writepages
> > - f2fs_write_node_pages
> > - f2fs_balance_fs_bg - write_checkpoint
> > - build_free_nids - flush_nat_entries
> > - __build_free_nids - __flush_nat_entry_set
> > - ra_meta_pages - get_next_nat_page
> > - current_nat_addr - set_to_next_nat
> > [do nat_bitmap checking] - f2fs_change_bit
>
> Both flows were protected by nat_tree_lock, so we don't need to worry about such
> case?
The nat_tree_lock doesn't cover ra_meta_pages in proc A.
Thanks,
>
> Thanks,
>
> >
> > For proc A, nat_bitmap and nat_bitmap_mir would be compared without lock_op and
> > nm_i->nat_tree_lock, while proc B is changing nat_bitmap/nat_bitmap_ver in cp.
> >
> > So it is normal for nat_bitmap/nat_bitmap diffrence under such scenario.
> >
> > This patch fix this by removing the monitoring point.
> >
> > [Fix: 599a09b f2fs: check in-memory nat version bitmap]
> > Signed-off-by: Hou Pengyang <houpengyang@huawei.com>
> > ---
> > fs/f2fs/node.h | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
> > index d3d2893..3fc9c4b 100644
> > --- a/fs/f2fs/node.h
> > +++ b/fs/f2fs/node.h
> > @@ -209,12 +209,6 @@ static inline pgoff_t current_nat_addr(struct f2fs_sb_info *sbi, nid_t start)
> > (seg_off << sbi->log_blocks_per_seg << 1) +
> > (block_off & (sbi->blocks_per_seg - 1)));
> >
> > -#ifdef CONFIG_F2FS_CHECK_FS
> > - if (f2fs_test_bit(block_off, nm_i->nat_bitmap) !=
> > - f2fs_test_bit(block_off, nm_i->nat_bitmap_mir))
> > - f2fs_bug_on(sbi, 1);
> > -#endif
> > -
> > if (f2fs_test_bit(block_off, nm_i->nat_bitmap))
> > block_addr += sbi->blocks_per_seg;
> >
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
next prev parent reply other threads:[~2017-02-24 17:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 9:18 [PATCH 1/3] f2fs: init local extent_info to avoid stale stack info in tp Hou Pengyang
2017-02-23 9:18 ` [PATCH 2/3] f2fs: remove unsafe bitmap checking Hou Pengyang
2017-02-24 11:12 ` Chao Yu
2017-02-24 17:45 ` Jaegeuk Kim [this message]
2017-02-25 0:52 ` Chao Yu
2017-02-25 2:03 ` Jaegeuk Kim
2017-02-25 2:14 ` Chao Yu
2017-02-25 18:11 ` Jaegeuk Kim
2017-02-23 9:18 ` [PATCH 3/3] f2fs: skip dirty bitmap scanning when no dirty segments Hou Pengyang
2017-02-23 19:03 ` Jaegeuk Kim
2017-02-24 2:01 ` Hou Pengyang
2017-02-24 11:09 ` [PATCH 1/3] f2fs: init local extent_info to avoid stale stack info in tp Chao Yu
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=20170224174541.GA39009@jaegeuk.local \
--to=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=yuchao0@huawei.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;
as well as URLs for NNTP newsgroup(s).