Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4813090imj; Wed, 13 Feb 2019 01:18:24 -0800 (PST) X-Google-Smtp-Source: AHgI3IYgtu/AEoagx3uFv4mlnsSBs+P7y8wrFyneNorvuRBQSmHJlIJJfunndeyAe42NU8k5uLse X-Received: by 2002:a62:4414:: with SMTP id r20mr1556832pfa.37.1550049504740; Wed, 13 Feb 2019 01:18:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550049504; cv=none; d=google.com; s=arc-20160816; b=veBZyjJjsyBLBfko5BJSItdHZGrBIZck4icGU/pvfqg2dITQdLFm1txGkCWeWWyjnV yN1SwErX2k+6lHj6I8xTUpDO24yOeVZE5T5mWIC0zt8InQUiQngq+DQIrVSlmEQNbs2k E8H4C7H7Sg3xVMe7QHovqhOCKcEarKUTVs3aHMIGjyRfZQXO12Psu3YRVQfFwQ+58MJW 2mBRvuiDy2FaHLbjNPMhei4KrBdd3Hf1sKrhpsZf+FibeHe7A6u9h/L0GRSRUp0q4u1Z hOqjoLBDsI85YO0LnSMsGwX59/RApm6OheNrCz2mxuZONS9yMuKlvD0XhcU4J162W9lb pejw== 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:to:subject; bh=ePRXcY6c3m8NYnoYXBdVN2Lc68lZzEGDX4WgTs989ag=; b=seMCQqrb2w+o5gJNArR1ZUkSHk0lFU7O/UycoRKc9OfCzuFC0yVbrIew/EXHmOgYNZ Rym8p2CPVNfjHFoRfGg3yk/4irqe8pmB2hewhus0nkuaQ8AWBC3Of88ujIVs8hnut9x+ xY6Gp0Ml6E06KJT8vK6vLYmvrgOZDS2oVlYBLP7Cqx9puk/2kHeqKgeQWmM9id9CyHtP kZz1pmn3+rCiqaJ3iY1YuqbtbUkpkgusKa03MKpnbml38j1uOloVI7uluHSnM1bNw2Ln OXThdSUAw/+VZWzmlJx1AbX/WPOD1tTlUUcTG23TDj8n2OksSkxNTIT/C83Hl9FeaEjW YnbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q19si14197792pgv.436.2019.02.13.01.18.07; Wed, 13 Feb 2019 01:18:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729156AbfBMDm1 (ORCPT + 99 others); Tue, 12 Feb 2019 22:42:27 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:3197 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727614AbfBMDm1 (ORCPT ); Tue, 12 Feb 2019 22:42:27 -0500 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 623AB5D5F434A0FFBD01; Wed, 13 Feb 2019 11:42:25 +0800 (CST) Received: from [127.0.0.1] (10.134.22.195) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.408.0; Wed, 13 Feb 2019 11:42:22 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG To: Jaegeuk Kim , , References: <20190212023343.52215-1-jaegeuk@kernel.org> From: Chao Yu Message-ID: Date: Wed, 13 Feb 2019 11:42:23 +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: <20190212023343.52215-1-jaegeuk@kernel.org> 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 2019/2/12 10:33, Jaegeuk Kim wrote: > If we met this once, let fsck.f2fs clear this only. > Note that, this addresses all the subtle fault injection test. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/checkpoint.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > index 03fea4efd64b..10a3ada28715 100644 > --- a/fs/f2fs/checkpoint.c > +++ b/fs/f2fs/checkpoint.c > @@ -1267,8 +1267,6 @@ static void update_ckpt_flags(struct f2fs_sb_info *sbi, struct cp_control *cpc) > > if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > - else > - __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); I didn't get it, previously, if we didn't persist all quota file's data in checkpoint, then we will tag CP_QUOTA_NEED_FSCK_FLAG in CP area, but in current checkpoint, we have persisted all quota file's data, quota files are consistent with all other files in filesystem, why we can't remove this NEED_FSCK flag..? Thanks, > > if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >