Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp360598pxp; Wed, 16 Mar 2022 07:17:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOFMg5l1LIY+QbqfO+F9fvUSAbExstLkDlmmltXKn8duwiDp1ArAbyaMSoqo8Ol4KrmXCK X-Received: by 2002:a65:4c4e:0:b0:375:5fb1:6a54 with SMTP id l14-20020a654c4e000000b003755fb16a54mr28888345pgr.231.1647440236589; Wed, 16 Mar 2022 07:17:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647440236; cv=none; d=google.com; s=arc-20160816; b=noh/NedgPZT8c/0ic5Alef5cOzhzQLzeUTWUIkNYL+MIx44ukD9cadi9tVqpGF5Xpb Xy3mYyePGv11sg06azZW3BoGf+aL+jQ8334kKfzlADg9/Oj83DVtax5A4Cwg4Z8bZruu BVasSzOi+QdMPX/8nUQB1hTgIY98iVOPZxw4SBGBgu6xCYU/JuhxsyQCulSZZCOUwhKz 4kyBuGIO+cvYO07TphBoOsQ2aO1cq1c3mvBMBYEBGafMWut2h4u5KScVZm17U1tcDeEi wtUAYFEdde+Q9RfRgqLeXkA98o+ZEFPFbqocfztNRCaMlHPEtdU0Pn7JIDle4u4zC8be mTqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TjVTI7QJ/uZeKWcoHxzpSq+Ea+tqRe0EPcb1hwlSoZQ=; b=KTJQp41jh6iHwDn5d6pd+dLKVMSApDyAdExEk6Ke6qdrCLmat4DfosgRZJz9nRJKS0 TCneyv0O7ad62rN/9txW59NTIq8jF2Ve74CI9M3TT6/LMS1wCH6NvRFUs9ckrfnuolNy io4y7vGWyNB6sN3xmrx+9NV7sJsSms5PAcuyTjHI9PNvYg75e/DXd//biboLF5fUIPIH U66sqvRXYJJbne0az0xSDmoD2oRpUb+tkJAzRsYocl16dxgEkMDenDPl3wpbEEK6mPdB KuBeZw5JiznvmfzGYANrJtIDNfH1e1XgjLGbQWDi3ZAJnwGFil96/XYwJwb61uWTijxT COGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i190-20020a6387c7000000b003813ba1db56si2059746pge.230.2022.03.16.07.16.55; Wed, 16 Mar 2022 07:17:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350797AbiCORz7 (ORCPT + 99 others); Tue, 15 Mar 2022 13:55:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350793AbiCORz5 (ORCPT ); Tue, 15 Mar 2022 13:55:57 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A27D593B4 for ; Tue, 15 Mar 2022 10:54:40 -0700 (PDT) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22FHsPUh006667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Mar 2022 13:54:26 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id BC6BE15C3E98; Tue, 15 Mar 2022 13:54:25 -0400 (EDT) Date: Tue, 15 Mar 2022 13:54:25 -0400 From: "Theodore Ts'o" To: zhanchengbin Cc: linux-ext4@vger.kernel.org, linfeilong , liuzhiqiang26@huawei.com Subject: Re: e2fsck: do not skip deeper checkers when s_last_orphan list has truncated inodes Message-ID: References: <647cc60d-18d4-ab53-6c91-52c1f6d29c3a@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <647cc60d-18d4-ab53-6c91-52c1f6d29c3a@huawei.com> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Mar 15, 2022 at 04:01:45PM +0800, zhanchengbin wrote: > If the system crashes when a file is being truncated, we will get a > problematic inode, > and it will be added into fs->super->s_last_orphan. > When we run `e2fsck -a img`, the s_last_orphan list will be traversed and > deleted. > During this period, orphan inodes in the s_last_orphan list with > i_links_count==0 can > be deleted, and orphan inodes with i_links_count !=0 (ex. the truncated > inode) > cannot be deleted. However, when there are some orphan inodes with > i_links_count !=0, > the EXT2_VALID_FS is still assigned to fs->super->s_state, the deeper > checkers are skipped > with some inconsistency problems. That's not supposed to happen. We regularly put inodes on the orphan list when they are being truncated so that if we crash, the truncation operation can be completed as part of the journal recovery and remount operation. This is true regardles sof whether the recovery is done by e2fsck or by the kernel. If a crash during a truncate leads to an inconsistent file system after the file system is mounted, or after e2fsck does the journal replay and orphan inode list processing, that's a kernel bug, and we should fix the bug in the kernel. Do you have a reliable reproducer for this situation? Thanks, - Ted