linux-kernel - Re: [f2fs-dev] [PATCH] f2fs: fix to correct freed section number during gc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 25 Sep 2015 20:43:57 +0800
From:	Chao Yu <yuchaochina@...mail.com>
To:	Jaegeuk Kim <jaegeuk@...nel.org>
CC:	Chao Yu <chao2.yu@...sung.com>, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to correct freed section number during gc

Hi Jaegeuk,

> On Sep 24, 2015, at 5:08 AM, Jaegeuk Kim <jaegeuk@...nel.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@...nel.org]
>>> Sent: Wednesday, September 23, 2015 6:54 AM
>>> To: Chao Yu
>>> Cc: linux-f2fs-devel@...ts.sourceforge.net; linux-kernel@...r.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@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/