[PATCH] f2fs: fix to correct freed section number during gc

[PATCH] f2fs: fix to correct freed section number during gc

[Chao Yu]

We pass 'nfree' to has_not_enough_free_secs to check whether there is
enough free section, but 'nfree' indicates the number of segment gced,
should alter the value to section number.

Signed-off-by: Chao Yu <chao2.yu@samsung.com>
---
 fs/f2fs/gc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index e932740..7ad2a60 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -817,7 +817,8 @@ gc_more:
 	if (unlikely(f2fs_cp_error(sbi)))
 		goto stop;
 
-	if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
+	if (gc_type == BG_GC &&
+		has_not_enough_free_secs(sbi, nfree / sbi->segs_per_sec)) {
 		gc_type = FG_GC;
 		if (__get_victim(sbi, &segno, gc_type) || prefree_segments(sbi))
 			write_checkpoint(sbi, &cpc);
@@ -839,7 +840,7 @@ gc_more:
 	if (gc_type == FG_GC)
 		sbi->cur_victim_sec = NULL_SEGNO;
 
-	if (has_not_enough_free_secs(sbi, nfree))
+	if (has_not_enough_free_secs(sbi, nfree / sbi->segs_per_sec))
 		goto gc_more;
 
 	if (gc_type == FG_GC)
-- 
2.5.2

Re: [PATCH] f2fs: fix to correct freed section number during gc

[Jaegeuk Kim]

Hi Chao,

On Tue, Sep 22, 2015 at 09:18:18PM +0800, Chao Yu wrote:
> We pass 'nfree' to has_not_enough_free_secs to check whether there is
> enough free section, but 'nfree' indicates the number of segment gced,
> should alter the value to section number.

Yeah, but I think we need to increase nfree only when an entire section is gced
completely, since sometimes nfree can be increased across sections.

Thanks,

> 
> Signed-off-by: Chao Yu <chao2.yu@samsung.com>
> ---
>  fs/f2fs/gc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index e932740..7ad2a60 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -817,7 +817,8 @@ gc_more:
>  	if (unlikely(f2fs_cp_error(sbi)))
>  		goto stop;
>  
> -	if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
> +	if (gc_type == BG_GC &&
> +		has_not_enough_free_secs(sbi, nfree / sbi->segs_per_sec)) {
>  		gc_type = FG_GC;
>  		if (__get_victim(sbi, &segno, gc_type) || prefree_segments(sbi))
>  			write_checkpoint(sbi, &cpc);
> @@ -839,7 +840,7 @@ gc_more:
>  	if (gc_type == FG_GC)
>  		sbi->cur_victim_sec = NULL_SEGNO;
>  
> -	if (has_not_enough_free_secs(sbi, nfree))
> +	if (has_not_enough_free_secs(sbi, nfree / sbi->segs_per_sec))
>  		goto gc_more;
>  
>  	if (gc_type == FG_GC)
> -- 
> 2.5.2

RE: [PATCH] f2fs: fix to correct freed section number during gc

[Chao Yu]

Hi Jaegeuk,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Wednesday, September 23, 2015 6:54 AM
> To: Chao Yu
> Cc: linux-f2fs-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] f2fs: fix to correct freed section number during gc
> 
> Hi Chao,
> 
> On Tue, Sep 22, 2015 at 09:18:18PM +0800, Chao Yu wrote:
> > We pass 'nfree' to has_not_enough_free_secs to check whether there is
> > enough free section, but 'nfree' indicates the number of segment gced,
> > should alter the value to section number.
> 
> Yeah, but I think we need to increase nfree only when an entire section is gced
> completely, since sometimes nfree can be increased across sections.

Agree, I will fix that.

Still have one question, for foreground gc, why would we give up retry writing
out pages of last victim, but trying to select another victim for cleanup?
Will new introduced method cause long latency for caller than before?

Thanks,

Re: [PATCH] f2fs: fix to correct freed section number during gc

[Jaegeuk Kim]

Hi Chao,

On Wed, Sep 23, 2015 at 06:11:36PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -----Original Message-----
> > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> > Sent: Wednesday, September 23, 2015 6:54 AM
> > To: Chao Yu
> > Cc: linux-f2fs-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] f2fs: fix to correct freed section number during gc
> > 
> > Hi Chao,
> > 
> > On Tue, Sep 22, 2015 at 09:18:18PM +0800, Chao Yu wrote:
> > > We pass 'nfree' to has_not_enough_free_secs to check whether there is
> > > enough free section, but 'nfree' indicates the number of segment gced,
> > > should alter the value to section number.
> > 
> > Yeah, but I think we need to increase nfree only when an entire section is gced
> > completely, since sometimes nfree can be increased across sections.
> 
> Agree, I will fix that.
> 
> Still have one question, for foreground gc, why would we give up retry writing
> out pages of last victim, but trying to select another victim for cleanup?
> Will new introduced method cause long latency for caller than before?

Hmm. Very occasionally, I've seen that gc goes into an infinite loop to clean up
one victim. In order to avoid that, I added giving up and then doing gc again.
I think there is no problem in normal cases. Even in an abnormal case, I expect
that next victim would be selected again because that should have lowest moving
cost.

> 
> Thanks,

Re: [PATCH] f2fs: fix to correct freed section number during gc

[Chao Yu]

Hi Jaegeuk,

> On Sep 24, 2015, at 5:08 AM, Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> 
> Hi Chao,
> 
> On Wed, Sep 23, 2015 at 06:11:36PM +0800, Chao Yu wrote:
>> Hi Jaegeuk,
>> 
>>> -----Original Message-----
>>> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
>>> Sent: Wednesday, September 23, 2015 6:54 AM
>>> To: Chao Yu
>>> Cc: linux-f2fs-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
>>> Subject: Re: [PATCH] f2fs: fix to correct freed section number during gc
>>> 
>>> Hi Chao,
>>> 
>>> On Tue, Sep 22, 2015 at 09:18:18PM +0800, Chao Yu wrote:
>>>> We pass 'nfree' to has_not_enough_free_secs to check whether there is
>>>> enough free section, but 'nfree' indicates the number of segment gced,
>>>> should alter the value to section number.
>>> 
>>> Yeah, but I think we need to increase nfree only when an entire section is gced
>>> completely, since sometimes nfree can be increased across sections.
>> 
>> Agree, I will fix that.
>> 
>> Still have one question, for foreground gc, why would we give up retry writing
>> out pages of last victim, but trying to select another victim for cleanup?
>> Will new introduced method cause long latency for caller than before?
> 
> Hmm. Very occasionally, I've seen that gc goes into an infinite loop to clean up
> one victim. In order to avoid that, I added giving up and then doing gc again.
> I think there is no problem in normal cases. Even in an abnormal case, I expect
> that next victim would be selected again because that should have lowest moving
> cost.

Got it, thanks for your explanation! :)

I have sent the v2 patch, please help to review.

Thanks,

> 
>> 
>> Thanks,
> 
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


------------------------------------------------------------------------------