Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1578186pxb; Thu, 28 Jan 2021 22:39:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJwDi7LkU3S79OUWbH4X3ESG5I4ePYMgl4UjeGdYo9P+0gLSaqe9OKxhEvor/M8yOEkPv4gh X-Received: by 2002:a50:9ee9:: with SMTP id a96mr3480737edf.343.1611902379648; Thu, 28 Jan 2021 22:39:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611902379; cv=none; d=google.com; s=arc-20160816; b=pgdMipsAM2VO3wW87iVceg/M2esuOFpAKuZqjcLhDA1nHikeo9AeHR8ecFd6iA770M LH7j0UO8r0A0XBuHbpt53LLW6ThYubvtZIlS2KaE5DasRxCMJsoxOmAtYR2hQhblkkju wt9YixVUlVJUDl9p4pKr9BMGaBaKEo7WMIr7b/kIUewFXdjLcGRGbRoBPT9qaN3Wa/Jd fexjrB/5qb5b/fa6uI1bX24XejOAarb+V4rR64Q0DyUs59WIyJwI3fbEwGrL6ug3OSjJ as6xgV6KbmEH3XWQKr07k64hEVyfW20aLjOGOppXpECq89mb7vWkLvT23BofGo4UI4jW IE8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=LbJJubOytysCJX1zl5N9G6EYXsLc/U/RcefmO13r0Ps=; b=WLVh9zWZ9kEFxfb2or3hL2UpCGNjqB8FOh+cbWHoJixMNZTvVOZqvlT6HMMGRYjAjX sp0wN9fkx7sgyf5Jc0xNcpsaThCDyAsT+qPV2k72H5n6CNdWj0VMQRNKDMap0KqPuK3E L7Ll9CW513L9YJj7ShncXOrZ8PyzFxt33loJujc/OZKhBZnBRlXEob15K8Euk8oMZcdC 6mXw/jV4PpZ2/1Se6QMzPugxKn7UuYWHGtfxNZJRC3uVG1jbUAEZY5JMCScNeHCVaf3N YDuUFP73XmG6qFgNEj4DEgc5Gn1EpHOlTOWE7DYqObUAZrmsQiNe3fQcRCtuMM9S7NYl iIqg== 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 k19si4227968ejc.406.2021.01.28.22.39.15; Thu, 28 Jan 2021 22:39:39 -0800 (PST) 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 S232051AbhA2Ggk (ORCPT + 99 others); Fri, 29 Jan 2021 01:36:40 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:11908 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231909AbhA2Ggg (ORCPT ); Fri, 29 Jan 2021 01:36:36 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4DRncz3RJYzjDr1; Fri, 29 Jan 2021 14:34:43 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.213) with Microsoft SMTP Server (TLS) id 14.3.498.0; Fri, 29 Jan 2021 14:35:41 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to avoid inconsistent quota data From: Chao Yu To: CC: , References: <20210128090256.73910-1-yuchao0@huawei.com> Message-ID: <62062195-b551-c5c7-7165-228e59852904@huawei.com> Date: Fri, 29 Jan 2021 14:35:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20210128090256.73910-1-yuchao0@huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/1/28 17:02, Chao Yu wrote: > From: Yi Chen > > Occasionally, quota data may be corrupted detected by fsck: > > Info: checkpoint state = 45 : crc compacted_summary unmount > [QUOTA WARNING] Usage inconsistent for ID 0:actual (1543036928, 762) != expected (1543032832, 762) > [ASSERT] (fsck_chk_quota_files:1986) --> Quota file is missing or invalid quota file content found. > [QUOTA WARNING] Usage inconsistent for ID 0:actual (1352478720, 344) != expected (1352474624, 344) > [ASSERT] (fsck_chk_quota_files:1986) --> Quota file is missing or invalid quota file content found. > > [FSCK] Unreachable nat entries [Ok..] [0x0] > [FSCK] SIT valid block bitmap checking [Ok..] > [FSCK] Hard link checking for regular file [Ok..] [0x0] > [FSCK] valid_block_count matching with CP [Ok..] [0xdf299] > [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x2b01] > [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x2b01] > [FSCK] valid_inode_count matched with CP [Ok..] [0x2665] > [FSCK] free segment_count matched with CP [Ok..] [0xcb04] > [FSCK] next block offset is free [Ok..] > [FSCK] fixing SIT types > [FSCK] other corrupted bugs [Fail] > > The root cause is: > If we open file w/ readonly flag, disk quota info won't be initialized > for this file, however, following mmap() will force to convert inline > inode via f2fs_convert_inline_inode(), which may increase block usage > for this inode w/o updating quota data, it causes inconsistent disk quota > info. > > The issue will happen in following stack: > open(file, O_RDONLY) > mmap(file) > - f2fs_convert_inline_inode > - f2fs_convert_inline_page > - f2fs_reserve_block > - f2fs_reserve_new_block > - f2fs_reserve_new_blocks > - f2fs_i_blocks_write > - dquot_claim_block > inode->i_blocks increase, but the dqb_curspace keep the size for the dquots > is NULL. > > To fix this issue, let's call dquot_initialize() anyway in both > f2fs_truncate() and f2fs_convert_inline_inode() functions to avoid potential > inconsistent quota data issue. > > Fixes: 0abd675e97e6 ("f2fs: support plain user/group quota") > Signed-off-by: Daiyue Zhang > Signed-off-by: Dehe Gu > Signed-off-by: Junchao Jiang > Signed-off-by: Ge Qiu > Signed-off-by: Yi Chen [Chao Yu: clean up commit message a bit] Reviewed-by: Chao Yu Thanks,