Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1026067ybt; Fri, 19 Jun 2020 22:03:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3EkZj9/6m2hW5OWr4uhyElvX/78DwTwOmPay7e0pW88Yn4FhHiWKn0HgA6kNzd4dMROhj X-Received: by 2002:a17:906:b15:: with SMTP id u21mr1461237ejg.520.1592629438522; Fri, 19 Jun 2020 22:03:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592629438; cv=none; d=google.com; s=arc-20160816; b=kUHyuQ2HqQ1frMG9gldH+sKQnTddGyNdgzJee0o8V2x9b/rfO5t7uUGa5ynn8URcjm hiU2j77mpDW+sFzISDT4HzUA/h7ZBYsjRrh8U7xCZsLuyDSSLCCHPZ04faEe4JEPUxYu e949RFG/jv2S9J9aoySG/05WAWJx2OkMYLwQQPSE9gG9nikODqI9cYLwb/k8d5GBZECj V5ofZ69Jch+LwwEKQnirHUrIDZ/tRTNM3+/9NQevaojLD4d5y0BpAfRLeBGgz5VDi9wn ppVfdwk2g/C1FSRr36rlnoXbJ7jt8Pc9gh4ePSkScOfs+UZjDOO6QgbQoUw9oQHrDMAf d8Dg== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=zwyvK/lvkZlBuQn1+NTbcr8QwqRvDY1V0s4Bk70fkEs=; b=Gcmhwa4myj07UIZk8wt8qAJL4TSTOBtOU0Imi54tG9uUV5FIF5x6Ol6J161E9AdjM/ O606nJKB+hlzjcQ6d16nQ4sgrFkOHRFqdqPbwJITmsmdFWrWHG7pq9ardpNofhXvsiDy q8bzA81+asB4/jDNOQGpKwJfSFEwfOij/hcI5cDKFc/Y+hRJ0y05MRPNYNRjUBDtE+l0 PyG78HC858gbhzWKslwoUnqZeeSfWbvfD3FeShMi8PUIfR3e0zrAGEMTNm1+H9pKW6BO K0EO8P0XLO7D79D7woVAeSLH6S3cIX+Y0FnF3HU1PWZfvVisbaKiogDVifgFFvZkI2R1 j1iQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 y24si4549678ejw.713.2020.06.19.22.03.35; Fri, 19 Jun 2020 22:03:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732110AbgFTCxg (ORCPT + 99 others); Fri, 19 Jun 2020 22:53:36 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:54918 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732006AbgFTCxf (ORCPT ); Fri, 19 Jun 2020 22:53:35 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 866D37C39C1D07AFF78E; Sat, 20 Jun 2020 10:53:33 +0800 (CST) Received: from huawei.com (10.175.127.227) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Sat, 20 Jun 2020 10:53:21 +0800 From: "zhangyi (F)" To: , , CC: , , , Subject: [PATCH v3 3/5] ext4: remove write io error check before read inode block Date: Sat, 20 Jun 2020 10:54:25 +0800 Message-ID: <20200620025427.1756360-4-yi.zhang@huawei.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <20200620025427.1756360-1-yi.zhang@huawei.com> References: <20200620025427.1756360-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-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org After we add async write error check in ext4_journal_get_write_access(), we can remove the partial fix for filesystem inconsistency problem caused by reading old data from disk, which 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 f68afc5c0b2d..79b73a86ef6c 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4289,15 +4289,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