From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E90D5C433E0 for ; Wed, 17 Jun 2020 11:58:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D381B20DD4 for ; Wed, 17 Jun 2020 11:58:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726845AbgFQL6t (ORCPT ); Wed, 17 Jun 2020 07:58:49 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:35150 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726816AbgFQL6s (ORCPT ); Wed, 17 Jun 2020 07:58:48 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 8E58374B058FB3BC4BEA; Wed, 17 Jun 2020 19:58:46 +0800 (CST) Received: from huawei.com (10.175.127.227) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Wed, 17 Jun 2020 19:58:35 +0800 From: "zhangyi (F)" To: , , CC: , , , Subject: [PATCH v2 5/5] ext4: remove write io error check before read inode block Date: Wed, 17 Jun 2020 19:59:47 +0800 Message-ID: <20200617115947.836221-6-yi.zhang@huawei.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <20200617115947.836221-1-yi.zhang@huawei.com> References: <20200617115947.836221-1-yi.zhang@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-CFilter-Loop: Reflected Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org After we add ext4_end_buffer_async_write() callback into block layer to detect metadata buffer's async write error in the background, we can remove the partial fix for filesystem inconsistency problem caused by reading old data from disk in commit <9c83a923c67d> "ext4: don't read inode block if the buffer has a write error". Signed-off-by: zhangyi (F) --- fs/ext4/inode.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 8ccb6996c384..b2fc1aef3886 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4281,15 +4281,6 @@ static int __ext4_get_inode_loc(struct inode *inode, if (!buffer_uptodate(bh)) { lock_buffer(bh); - /* - * If the buffer has the write error flag, we have failed - * to write out another inode in the same block. In this - * case, we don't have to read the block because we may - * read the old inode data successfully. - */ - if (buffer_write_io_error(bh) && !buffer_uptodate(bh)) - set_buffer_uptodate(bh); - if (buffer_uptodate(bh)) { /* someone brought it uptodate while we waited */ unlock_buffer(bh); -- 2.25.4