All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wanpeng Li <wanpeng.li@linux.intel.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Changman Lee <cm224.lee@samsung.com>,
	Chao Yu <chao2.yu@samsung.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Wanpeng Li <wanpeng.li@linux.intel.com>
Subject: Re: [PATCH 2/3] f2fs: fix get stale meta pages when build free nids
Date: Mon, 9 Mar 2015 12:24:53 +0800	[thread overview]
Message-ID: <20150309042453.GA27895@kernel> (raw)
In-Reply-To: <20150309041847.GC4472@jaegeuk-mac02>

Hi Jaegeuk,
On Sun, Mar 08, 2015 at 09:18:47PM -0700, Jaegeuk Kim wrote:
>Hi Wanpeng,
>
>On Mon, Mar 09, 2015 at 11:00:54AM +0800, Wanpeng Li wrote:
>> The blocks of nat pages to be scanned will be readahead when build free 
>> nids. The start blkno will be adjusted to 0 when the intended range over 
>> max_nids, then function ra_meta_pages readahead the right blkno, however, 
>> function get_current_nat_page which is called in build_free_nids still 
>> get the meta pages w/ stale blkno, this patch fix it by adjusting the nid 
>> and the blkno which will be readahead in avdance in order to readahead and 
>> get the right meta pages.
>> 
>> Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
>> ---
>>  fs/f2fs/checkpoint.c | 3 ---
>>  fs/f2fs/node.c       | 9 ++++++++-
>>  2 files changed, 8 insertions(+), 4 deletions(-)
>> 
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index 53bc328..aedb441 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -129,9 +129,6 @@ int ra_meta_pages(struct f2fs_sb_info *sbi, block_t start, int nrpages, int type
>>  
>>  		switch (type) {
>>  		case META_NAT:
>> -			if (unlikely(blkno >=
>> -					NAT_BLOCK_OFFSET(NM_I(sbi)->max_nid)))
>> -				blkno = 0;
>>  			/* get nat block addr */
>>  			fio.blk_addr = current_nat_addr(sbi,
>>  					blkno * NAT_ENTRY_PER_BLOCK);
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 1a7e925..8751375 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1509,13 +1509,20 @@ static void build_free_nids(struct f2fs_sb_info *sbi)
>>  	struct f2fs_summary_block *sum = curseg->sum_blk;
>>  	int i = 0;
>>  	nid_t nid = nm_i->next_scan_nid;
>> +	block_t blkno = NAT_BLOCK_OFFSET(nid);
>>  
>>  	/* Enough entries */
>>  	if (nm_i->fcnt > NAT_ENTRY_PER_BLOCK)
>>  		return;
>>  
>> +	if (unlikely(blkno >=
>> +			NAT_BLOCK_OFFSET(NM_I(sbi)->max_nid))) {
>> +		blkno = 0;
>> +		nid = 0;
>> +	}
>
>The assumption here is that the nid does not exceeed max_nid, since the
>previous call already set next_scan_nid to 0, if it exceeds max_nid.
>So, we don't need to do like this.

So get_current_nat_page in while(1) still get the wrong meta page for
one time, right? The nid will be set to 0 in the second round.

Regards,
Wanpeng Li 

>
>BTW, even if ra_meta_pages doesn't get the below condition,
>		if (unlikely(blkno >=
>				NAT_BLOCK_OFFSET(NM_I(sbi)->max_nid)))
>			blkno = 0;
>IMO, it is still worth to remain that to avoid any bugs due to further code
>changes. It makes sense that unlikely was used for this too.
>
>Thanks,
>
>> +
>>  	/* readahead nat pages to be scanned */
>> -	ra_meta_pages(sbi, NAT_BLOCK_OFFSET(nid), FREE_NID_PAGES, META_NAT);
>> +	ra_meta_pages(sbi, blkno, FREE_NID_PAGES, META_NAT);
>>  
>>  	while (1) {
>>  		struct page *page = get_current_nat_page(sbi, nid);
>> -- 
>> 1.9.1

  reply	other threads:[~2015-03-09  4:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09  3:00 [PATCH 1/3] f2fs: guarantee node/meta inode number won't be reused Wanpeng Li
2015-03-09  3:00 ` [PATCH 2/3] f2fs: fix get stale meta pages when build free nids Wanpeng Li
2015-03-09  3:00   ` Wanpeng Li
2015-03-09  4:18   ` Jaegeuk Kim
2015-03-09  4:24     ` Wanpeng Li [this message]
2015-03-09 10:01       ` Chao Yu
2015-03-09  3:00 ` [PATCH 3/3] f2fs: fix unlocked nat set cache operation Wanpeng Li
2015-03-09  3:00   ` Wanpeng Li
2015-03-09  3:52 ` [PATCH 1/3] f2fs: guarantee node/meta inode number won't be reused Jaegeuk Kim

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=20150309042453.GA27895@kernel \
    --to=wanpeng.li@linux.intel.com \
    --cc=chao2.yu@samsung.com \
    --cc=cm224.lee@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --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.