Message ID | 20230210032044.146115-1-yebin@huaweicloud.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp716636wrn; Thu, 9 Feb 2023 18:59:50 -0800 (PST) X-Google-Smtp-Source: AK7set8E9kmTrjT296XE9kuX62FgtJEyifM0oPxrekbFoc9Jq5MTQkXbOIE7wK7n9r1T9jpeVREN X-Received: by 2002:a17:902:f789:b0:199:4218:2257 with SMTP id q9-20020a170902f78900b0019942182257mr6655311pln.28.1675997989976; Thu, 09 Feb 2023 18:59:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675997989; cv=none; d=google.com; s=arc-20160816; b=z6D/cbi9p0phwkLjK5u8LN/m6vwKe1LAt8+3ic0hB8AIG/O8btly6Y1AoHLzOG5NXh XedRPIq8ATn0tItwGcoQeNmNtXhPU4PDpg5sD39XTWHqd2vf2PypqybgI9AG7JPm38nD QUKvblO81dfI3BeaHFabwew0MAHujQ6agFY0fn1F7NQDJgBu8XGmWK1crOTqhTx7TvNW Yl+liUAEl8ju/ys8e//INtntxWt2HQEAgXRja/S7mEkHRlzzhDgD8ANUf5ywTz/nCKEA GYx3H+hdQaJeYP4s0qpm3qVFQZxzxAA3EN7vIlKAK4BQglILkIC7XXXs5vcie1yyawGM 17Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=UwUP2npZyXSwvwQMozrm+B9uBQm8qk/wKVGCgZ6ZrOY=; b=sgzDoNKraG9RgG37Qev+5FYm14DZ+r9K5vOQ2Lx9VX+GmjUu7tgHB7oXrXmijmelDQ v5G3UYBEeOwPX63N7iDCU2UdOeXQRDoSecFq66rYVRpMue8wHBapXIdDJmehpryUp+J6 o2G1SdEUSWtC84ZG+0OfxaV+ewkIDN1nY/HPVXqqW8NYXGbMC7DZWPBREmMUeUEOAoZe qKWycSpSlrrXeN/wvC4/qm1pE5f4+v5iZlcgpAGh9ylvq/jCsm/05tX8QDQYI/UURaYd oZ9meHVmbD6no6Nc+azpEqtEjilg9ODA00JyMaH7NBLUwj/JMVlRqtsYD3dAY6pwZgfd VT8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i1-20020a17090332c100b00198fdab0c8fsi3959656plr.13.2023.02.09.18.59.37; Thu, 09 Feb 2023 18:59:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230400AbjBJC5G (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Thu, 9 Feb 2023 21:57:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229596AbjBJC5F (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Feb 2023 21:57:05 -0500 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64FFB64656; Thu, 9 Feb 2023 18:57:03 -0800 (PST) Received: from mail02.huawei.com (unknown [172.30.67.143]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4PCdgG42zQz4f3m7b; Fri, 10 Feb 2023 10:56:58 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.127.227]) by APP3 (Coremail) with SMTP id _Ch0CgCHgR96suVjIkgqDA--.35208S4; Fri, 10 Feb 2023 10:57:00 +0800 (CST) From: Ye Bin <yebin@huaweicloud.com> To: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org Cc: linux-kernel@vger.kernel.org, jack@suse.cz, Ye Bin <yebin10@huawei.com> Subject: [PATCH v2 0/6] fix error flag covered by journal recovery Date: Fri, 10 Feb 2023 11:20:38 +0800 Message-Id: <20230210032044.146115-1-yebin@huaweicloud.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: _Ch0CgCHgR96suVjIkgqDA--.35208S4 X-Coremail-Antispam: 1UD129KBjvJXoW7WF47Cr43GFyrCr47Xr13urg_yoW8Cr4fp3 95Zr98KrWkZFyxJF93Aa1Ut3yrX34rCFy5WFnrWw1Iy345tr13Z3srtF15KFWUKr4Sqa1j qF18J34rG3WUKrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUgKb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1x MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJV Cq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBI daVFxhVjvjDU0xZFpf9x07UWE__UUUUU= X-CM-SenderInfo: p1hex046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757411268384083509?= X-GMAIL-MSGID: =?utf-8?q?1757411268384083509?= |
Series |
fix error flag covered by journal recovery
|
|
Message
Ye Bin
Feb. 10, 2023, 3:20 a.m. UTC
From: Ye Bin <yebin10@huawei.com>
Diff v2 vs v1:
Move call 'j_replay_prepare_callback' and 'j_replay_end_callback' from
ext4_load_journal() to jbd2_journal_recover().
When do fault injection test, got issue as follows:
EXT4-fs (dm-5): warning: mounting fs with errors, running e2fsck is recommended
EXT4-fs (dm-5): Errors on filesystem, clearing orphan list.
EXT4-fs (dm-5): recovery complete
EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro
EXT4-fs (dm-5): recovery complete
EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro
Without do file system check, file system is clean when do second mount.
Theoretically, the kernel will not clear fs error flag. In errors=remount-ro
mode the last super block is commit directly. So super block in journal is
not uptodate. When do jounral recovery, the uptodate super block will be
covered by jounral data. If super block submit all failed after recover
journal, then file system error flag is lost. When do "fsck -a" couldn't
repair file system deeply.
To solve above issue we need to do extra handle when do super block journal
recovery.
Ye Bin (6):
jbd2: introduce callback for recovery journal
ext4: introudce helper for jounral recover handle
jbd2: do extra handle when do journal recovery
ext4: remove backup for super block when recovery journal
ext4: fix super block checksum error
ext4: make sure fs error flag setted before clear journal error
fs/ext4/ext4_jbd2.c | 66 ++++++++++++++++++++++++++++++++++++++++++++
fs/ext4/ext4_jbd2.h | 2 ++
fs/ext4/super.c | 18 ++++--------
fs/jbd2/recovery.c | 27 ++++++++++++++++++
include/linux/jbd2.h | 11 ++++++++
5 files changed, 112 insertions(+), 12 deletions(-)
Comments
Hello! On Fri 10-02-23 11:20:38, Ye Bin wrote: > From: Ye Bin <yebin10@huawei.com> > > Diff v2 vs v1: > Move call 'j_replay_prepare_callback' and 'j_replay_end_callback' from > ext4_load_journal() to jbd2_journal_recover(). > > When do fault injection test, got issue as follows: > EXT4-fs (dm-5): warning: mounting fs with errors, running e2fsck is recommended > EXT4-fs (dm-5): Errors on filesystem, clearing orphan list. > EXT4-fs (dm-5): recovery complete > EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro > > EXT4-fs (dm-5): recovery complete > EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro > > Without do file system check, file system is clean when do second mount. > Theoretically, the kernel will not clear fs error flag. In errors=remount-ro > mode the last super block is commit directly. So super block in journal is > not uptodate. When do jounral recovery, the uptodate super block will be > covered by jounral data. If super block submit all failed after recover > journal, then file system error flag is lost. When do "fsck -a" couldn't > repair file system deeply. > To solve above issue we need to do extra handle when do super block journal > recovery. Thanks for the patches. Looking through the patches, I think this is a bit of an overengineering for the problem at hand. The only thing that is really worth preserving so that it is not lost after journal replay is the error information. So in ext4_load_journal() I would just save that if EXT4_ERROR_FS is set in es->s_state before journal replay and restore it after journal replay. Sure if the superblock write during journal replay succeeds but the write restoring the error information fails, we will loose the error information but that is so unlikely in practice that I don't think it is really worth complicating the code for it. Also the only downside is we will loose the information there is some error in the filesystem - we'll soon find that out again anyway :). Honza > > Ye Bin (6): > jbd2: introduce callback for recovery journal > ext4: introudce helper for jounral recover handle > jbd2: do extra handle when do journal recovery > ext4: remove backup for super block when recovery journal > ext4: fix super block checksum error > ext4: make sure fs error flag setted before clear journal error > > fs/ext4/ext4_jbd2.c | 66 ++++++++++++++++++++++++++++++++++++++++++++ > fs/ext4/ext4_jbd2.h | 2 ++ > fs/ext4/super.c | 18 ++++-------- > fs/jbd2/recovery.c | 27 ++++++++++++++++++ > include/linux/jbd2.h | 11 ++++++++ > 5 files changed, 112 insertions(+), 12 deletions(-) > > -- > 2.31.1 >
On 2023/2/10 19:56, Jan Kara wrote: > Hello! > > On Fri 10-02-23 11:20:38, Ye Bin wrote: >> From: Ye Bin <yebin10@huawei.com> >> >> Diff v2 vs v1: >> Move call 'j_replay_prepare_callback' and 'j_replay_end_callback' from >> ext4_load_journal() to jbd2_journal_recover(). >> >> When do fault injection test, got issue as follows: >> EXT4-fs (dm-5): warning: mounting fs with errors, running e2fsck is recommended >> EXT4-fs (dm-5): Errors on filesystem, clearing orphan list. >> EXT4-fs (dm-5): recovery complete >> EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro >> >> EXT4-fs (dm-5): recovery complete >> EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro >> >> Without do file system check, file system is clean when do second mount. >> Theoretically, the kernel will not clear fs error flag. In errors=remount-ro >> mode the last super block is commit directly. So super block in journal is >> not uptodate. When do jounral recovery, the uptodate super block will be >> covered by jounral data. If super block submit all failed after recover >> journal, then file system error flag is lost. When do "fsck -a" couldn't >> repair file system deeply. >> To solve above issue we need to do extra handle when do super block journal >> recovery. > > Thanks for the patches. Looking through the patches, I think this is a bit > of an overengineering for the problem at hand. The only thing that is > really worth preserving so that it is not lost after journal replay is the > error information. So in ext4_load_journal() I would just save that if > EXT4_ERROR_FS is set in es->s_state before journal replay and restore it > after journal replay. Sure if the superblock write during journal replay > succeeds but the write restoring the error information fails, we will loose > the error information but that is so unlikely in practice that I don't > think it is really worth complicating the code for it. Also the only > downside is we will loose the information there is some error in the > filesystem - we'll soon find that out again anyway :). > I think so, also add a error message if we failed to restoring the error information, it could let us know what happened. Thanks, Yi.
On 2023/2/10 19:56, Jan Kara wrote: > Hello! > > On Fri 10-02-23 11:20:38, Ye Bin wrote: >> From: Ye Bin <yebin10@huawei.com> >> >> Diff v2 vs v1: >> Move call 'j_replay_prepare_callback' and 'j_replay_end_callback' from >> ext4_load_journal() to jbd2_journal_recover(). >> >> When do fault injection test, got issue as follows: >> EXT4-fs (dm-5): warning: mounting fs with errors, running e2fsck is recommended >> EXT4-fs (dm-5): Errors on filesystem, clearing orphan list. >> EXT4-fs (dm-5): recovery complete >> EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro >> >> EXT4-fs (dm-5): recovery complete >> EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro >> >> Without do file system check, file system is clean when do second mount. >> Theoretically, the kernel will not clear fs error flag. In errors=remount-ro >> mode the last super block is commit directly. So super block in journal is >> not uptodate. When do jounral recovery, the uptodate super block will be >> covered by jounral data. If super block submit all failed after recover >> journal, then file system error flag is lost. When do "fsck -a" couldn't >> repair file system deeply. >> To solve above issue we need to do extra handle when do super block journal >> recovery. > Thanks for the patches. Looking through the patches, I think this is a bit > of an overengineering for the problem at hand. The only thing that is > really worth preserving so that it is not lost after journal replay is the > error information. So in ext4_load_journal() I would just save that if > EXT4_ERROR_FS is set in es->s_state before journal replay and restore it > after journal replay. Sure if the superblock write during journal replay > succeeds but the write restoring the error information fails, we will loose > the error information but that is so unlikely in practice that I don't > think it is really worth complicating the code for it. Also the only > downside is we will loose the information there is some error in the > filesystem - we'll soon find that out again anyway :). > > Honza Yes, this solution seems a little cumbersome, but to solve the problem of error information loss, I can only think of this solution. I re-analyzed the issue scenario. Because the error information of the last journal super block was not recorded. This will cause that the error flag will not be updated when the super block is submitted subsequently. However, when processing orphan list, the file system errors were recorded in the memory, and the orphan list were cleared directly, resulting in file system inconsistencies. To solve above isuue, i sent V3 patch. >> Ye Bin (6): >> jbd2: introduce callback for recovery journal >> ext4: introudce helper for jounral recover handle >> jbd2: do extra handle when do journal recovery >> ext4: remove backup for super block when recovery journal >> ext4: fix super block checksum error >> ext4: make sure fs error flag setted before clear journal error >> >> fs/ext4/ext4_jbd2.c | 66 ++++++++++++++++++++++++++++++++++++++++++++ >> fs/ext4/ext4_jbd2.h | 2 ++ >> fs/ext4/super.c | 18 ++++-------- >> fs/jbd2/recovery.c | 27 ++++++++++++++++++ >> include/linux/jbd2.h | 11 ++++++++ >> 5 files changed, 112 insertions(+), 12 deletions(-) >> >> -- >> 2.31.1 >>