Linux-f2fs-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: do not select same victim right again
Date: Tue, 17 Sep 2019 09:42:32 +0800
Message-ID: <ab9561c9-db27-2967-e6fc-accd9bc58747@huawei.com> (raw)
In-Reply-To: <20190916153736.GA2493@jaegeuk-macbookpro.roam.corp.google.com>

On 2019/9/16 23:37, Jaegeuk Kim wrote:
> On 09/16, Chao Yu wrote:
>> On 2019/9/9 20:04, Jaegeuk Kim wrote:
>>> On 09/09, Chao Yu wrote:
>>>> On 2019/9/9 16:06, Jaegeuk Kim wrote:
>>>>> On 09/09, Chao Yu wrote:
>>>>>> On 2019/9/9 9:25, Jaegeuk Kim wrote:
>>>>>>> GC must avoid select the same victim again.
>>>>>>
>>>>>> Blocks in previous victim will occupy addition free segment, I doubt after this
>>>>>> change, FGGC may encounter out-of-free space issue more frequently.
>>>>>
>>>>> Hmm, actually this change seems wrong by sec_usage_check().
>>>>> We may be able to avoid this only in the suspicious loop?
>>>>>
>>>>> ---
>>>>>  fs/f2fs/gc.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>>>> index e88f98ddf396..5877bd729689 100644
>>>>> --- a/fs/f2fs/gc.c
>>>>> +++ b/fs/f2fs/gc.c
>>>>> @@ -1326,7 +1326,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>>>>  		round++;
>>>>>  	}
>>>>>  
>>>>> -	if (gc_type == FG_GC)
>>>>> +	if (gc_type == FG_GC && seg_freed)
>>>>
>>>> That's original solution Sahitya provided to avoid infinite loop of GC, but I
>>>> suggest to find the root cause first, then we added .invalid_segmap for that
>>>> purpose.
>>>
>>> I've checked the Sahitya's patch. So, it seems the problem can happen due to
>>> is_alive or atomic_file.
>>
>> For some conditions, this doesn't help, for example, two sections contain the
>> same fewest valid blocks, it will cause to loop selecting them if it fails to
>> migrate blocks.
>>
>> How about keeping it as it is to find potential bug.
> 
> I think it'd be fine to merge this. Could you check the above scenario in more
> detail?

I haven't saw this in real scenario yet.

What I mean is if there is a bug (maybe in is_alive()) failing us to GC on one
section, when that bug happens in two candidates, there could be the same
condition that GC will run into loop (select A, fail to migrate; select B, fail
to migrate, select A...).

But I guess the benefit of this change is, if FGGC fails to migrate block due to
i_gc_rwsem race, selecting another section and later retrying previous one may
avoid lock race, right?

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>>>  		sbi->cur_victim_sec = NULL_SEGNO;
>>>>>  
>>>>>  	if (sync)
>>>>>
>>> .
>>>
> .
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply index

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09  1:25 Jaegeuk Kim
2019-09-09  1:25 ` [f2fs-dev] [PATCH 2/2] f2fs: avoid infinite GC loop due to stale atomic files Jaegeuk Kim
2019-09-09  3:03   ` Chao Yu
2019-09-09  7:30     ` Jaegeuk Kim
2019-09-09  7:54       ` Chao Yu
2019-09-09  8:01         ` Jaegeuk Kim
2019-09-09  8:05           ` Chao Yu
2019-09-09  8:21             ` Jaegeuk Kim
2019-09-09  8:27               ` Chao Yu
2019-09-09  8:38                 ` Jaegeuk Kim
2019-09-09  8:44                   ` Jaegeuk Kim
2019-09-09 11:26                   ` Chao Yu
2019-09-09 14:34                     ` Jaegeuk Kim
2019-09-10  0:59                       ` Chao Yu
2019-09-10 11:58                         ` Jaegeuk Kim
2019-09-10 12:04                           ` Chao Yu
2019-09-10 12:09                             ` Jaegeuk Kim
2019-09-16  1:15                               ` Chao Yu
2019-09-09  2:56 ` [f2fs-dev] [PATCH 1/2] f2fs: do not select same victim right again Chao Yu
2019-09-09  8:06   ` Jaegeuk Kim
2019-09-09 11:32     ` Chao Yu
2019-09-09 12:04       ` Jaegeuk Kim
2019-09-16  1:22         ` Chao Yu
2019-09-16 15:37           ` Jaegeuk Kim
2019-09-17  1:42             ` Chao Yu [this message]
2019-09-17 20:55               ` Jaegeuk Kim
2019-09-18  1:43                 ` Chao Yu
2019-09-18  3:12                   ` Jaegeuk Kim
2019-09-18  3:26                     ` Chao Yu
2019-09-18 16:47                       ` Jaegeuk Kim
2019-09-19  0:53                         ` Chao Yu
2019-09-19 17:11                           ` Jaegeuk Kim

Reply instructions:

You may reply publically 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=ab9561c9-db27-2967-e6fc-accd9bc58747@huawei.com \
    --to=yuchao0@huawei.com \
    --cc=jaegeuk@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

Linux-f2fs-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-f2fs-devel/0 linux-f2fs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-f2fs-devel linux-f2fs-devel/ https://lore.kernel.org/linux-f2fs-devel \
		linux-f2fs-devel@lists.sourceforge.net linux-f2fs-devel@archiver.kernel.org
	public-inbox-index linux-f2fs-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/net.sourceforge.lists.linux-f2fs-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox