Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2370377ybk; Sun, 17 May 2020 19:23:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwhlzlg5koDGA82JOnRB+DXE7Yg8ALRXCXfKSgLLgSPauaMzjv690+/tMJWGO7ByvguOvF X-Received: by 2002:a17:906:6055:: with SMTP id p21mr13454966ejj.316.1589768631929; Sun, 17 May 2020 19:23:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589768631; cv=none; d=google.com; s=arc-20160816; b=b0BlDQ/FmPDhQDndjSVSLjG0o9j9tDneWosOyZYF8mqrWSVWfk7QpaxyBS4X1CzLzM V5Ey1WR4Y9tzs/9evtHmPQoBaPEUUxrLYh7GPVXVSGOgikA9sdLuw77yprEMkVX7FCqG 2C9b3V13Z05AaDqm5IkNlUWguLKP+nrpD0yvpr97Wjp4S3/OnOPHm/IprEh928kMW39Q R9MGroeebsww3jsxXBn41DMvwNiXckVHXtiOnpkimIMpimiTLDuREfgUKLiRYjW7SZqD 7we+4zwheBy1FiI8TZ8yL/a0oI1emA+1zpnhPqE/+Mb5XDnDJINH2DlAnnlUUd6xYZR8 IU8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=9a74TipqmTTRValKhwMz6zMuseTiDPhPDRM9wlOEee4=; b=EgH6GPgxpkvufL3KMBMrojhfmykyk9sv33l4fS2TtPpCEjQhoBmCP1yxRe7dWOk6se yCOBUzTSkw1ERjmKyzmo7X/GfMokNz25HjS+/wnxpsDTKh3jS1L8lZIoHP1M7566GJYX TFTOMArSknmhtRZADPCl265/eYPCJvBKq3s6tAQXuUuWun/+DvLk4TE8sAip+fE36O/t ylWcPkAkk5sdjjzHrmbL+8LJDCVT3d+hq7LuB71IdHlZlfTcGNj2XrRXOYcw7Od08wZ2 E6NFBsLeAmuT7DmwHjlb/zQPL5P/fXt523RWmFmQivwXJGSetDqnJ+Gid+ev9t8XJp5h BkwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oq5si5835826ejb.395.2020.05.17.19.23.29; Sun, 17 May 2020 19:23:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726813AbgERCV0 (ORCPT + 99 others); Sun, 17 May 2020 22:21:26 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:42412 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726675AbgERCV0 (ORCPT ); Sun, 17 May 2020 22:21:26 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 7B2F8A7CA5DC1B82FDC8; Mon, 18 May 2020 10:21:24 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.201) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 18 May 2020 10:21:21 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: flush dirty meta pages when flushing them To: Jaegeuk Kim CC: , , References: <20200515021554.226835-1-jaegeuk@kernel.org> <9ba6e5ef-068d-a925-1eb9-107b0523666c@huawei.com> <20200515144509.GA46028@google.com> From: Chao Yu Message-ID: Date: Mon, 18 May 2020 10:21:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200515144509.GA46028@google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/5/15 22:45, Jaegeuk Kim wrote: > On 05/15, Chao Yu wrote: >> On 2020/5/15 10:15, Jaegeuk Kim wrote: >>> Let's guarantee flusing dirty meta pages to avoid infinite loop. >> >> What's the root cause? Race case or meta page flush failure? > > Investigating, but at least, this can avoid the inifinite loop there. Hmm... this fix may cover the root cause.. Thanks, > > V2: > >>From c60ce8e7178004fd6cba96e592247e43b5fd98d8 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim > Date: Wed, 13 May 2020 21:12:53 -0700 > Subject: [PATCH] f2fs: flush dirty meta pages when flushing them > > Let's guarantee flusing dirty meta pages to avoid infinite loop. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/checkpoint.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > index 620a386d82c1a..3dc3ac6fe1432 100644 > --- a/fs/f2fs/checkpoint.c > +++ b/fs/f2fs/checkpoint.c > @@ -1266,6 +1266,9 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int type) > if (unlikely(f2fs_cp_error(sbi))) > break; > > + if (type == F2FS_DIRTY_META) > + f2fs_sync_meta_pages(sbi, META, LONG_MAX, > + FS_CP_META_IO); > io_schedule_timeout(DEFAULT_IO_TIMEOUT); > } > finish_wait(&sbi->cp_wait, &wait); >