Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp210830ybt; Thu, 9 Jul 2020 20:16:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOVZ4RAirVwkDb4ERKux7J+jA6KMoQ4kWSReKhHEwAPoq90ogGG+Tah2hN7cMUf0NJ/lP2 X-Received: by 2002:a50:fd07:: with SMTP id i7mr41190058eds.221.1594351009230; Thu, 09 Jul 2020 20:16:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594351009; cv=none; d=google.com; s=arc-20160816; b=TZTrYeYpABKdQsRmg+pYa2M0YldSS9RIesGoE1CYsQO1gtpEUwN+0UnSx7PHcDS246 K3xa+KDpHwgzoGGuGk0Hlf+hxDBMinagxg+PQJEiwgB4JbEXwGvaMnauB//dRKVxbJCT ZUlELbvtQlyvDSIeLTJPQmru20md94aQrQDfs/vC5A73Ffq0cN6dU8DKV8nSYN9nET3F uvCYvXxIwcpIZmz4BmC1McBbskJFbRPtTmyCBc/ErNUGVSweeNxgEoxjRgMM4ZHk+K7/ 6M9TvinhgHwsojCHebqI/eP/Ee34AbCAeEH8SqosU8l7rKevuiHuMqOvuH0wS/izvat9 GZ8w== 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=LnaFUepZkbofcdBPoUTlsOj6IRkANIebRsgjDgqB7zo=; b=rCiLFpOr65DwAiUuQIBsPUgPQZ3IdMyn+saNK0MR+v94Ji8OFDKZDjCdAYzqrIrtfr qNwPwMYoK7P/adaFz/upmBQG9amCHlmphn9/Ldwjbws1C/klS8mOznitO+Eo9D1uVCQV TCCAXu0gI2WT0tB+FDo5ujchIXLy8PSOOeAQYS2otBOmSPBmguCVT7iVdX7LX6zX7HRA 074HzThHFu5GUzKC/4LaJ2rjKAtBOq/a5CpWK2d8qtRMrjWSD85hMkobPy5+w7+Eon6w +X/hesNZmAaKUfWjkDkqMRuFQnNvRZNwDRndVTAd6Wo65t7mg8fDT+7cqhK9z4QO2JBX m+mA== 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 k25si3030335ejv.672.2020.07.09.20.16.26; Thu, 09 Jul 2020 20:16:49 -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 S1726920AbgGJDPT (ORCPT + 99 others); Thu, 9 Jul 2020 23:15:19 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:7285 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726495AbgGJDPS (ORCPT ); Thu, 9 Jul 2020 23:15:18 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 599847F8CC46ECA42E9A; Fri, 10 Jul 2020 11:15:14 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.203) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 10 Jul 2020 11:15:13 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: don't skip writeback of quota data To: Jaegeuk Kim CC: , , References: <20200709053027.351974-1-jaegeuk@kernel.org> <2f4207db-57d1-5b66-f1ee-3532feba5d1f@huawei.com> <20200709190545.GA3001066@google.com> From: Chao Yu Message-ID: Date: Fri, 10 Jul 2020 11:15:12 +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: <20200709190545.GA3001066@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/7/10 3:05, Jaegeuk Kim wrote: > On 07/09, Chao Yu wrote: >> On 2020/7/9 13:30, Jaegeuk Kim wrote: >>> It doesn't need to bypass flushing quota data in background. >> >> The condition is used to flush quota data in batch to avoid random >> small-sized udpate, did you hit any problem here? > > I suspect this causes fault injection test being stuck by waiting for inode > writeback completion. With this patch, it has been running w/o any issue so far. > I keep an eye on this. Hmmm.. so that this patch may not fix the root cause, and it may hiding the issue deeper. How about just keeping this patch in our private branch to let fault injection test not be stuck? until we find the root cause in upstream codes. Thanks, > > Thanks, > >> >> Thanks, >> >>> >>> Signed-off-by: Jaegeuk Kim >>> --- >>> fs/f2fs/data.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c >>> index 44645f4f914b6..72e8b50e588c1 100644 >>> --- a/fs/f2fs/data.c >>> +++ b/fs/f2fs/data.c >>> @@ -3148,7 +3148,7 @@ static int __f2fs_write_data_pages(struct address_space *mapping, >>> if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING))) >>> goto skip_write; >>> >>> - if ((S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) && >>> + if (S_ISDIR(inode->i_mode) && >>> wbc->sync_mode == WB_SYNC_NONE && >>> get_dirty_pages(inode) < nr_pages_to_skip(sbi, DATA) && >>> f2fs_available_free_memory(sbi, DIRTY_DENTS)) >>> > . >