Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2243945pxj; Sun, 9 May 2021 20:36:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/UaU3GwY6UC6twVFcudYWIEplt4pzJj1UV99erc146GwXQL5avEL/WiTav8FunK77TBCi X-Received: by 2002:a02:764b:: with SMTP id z72mr19593531jab.144.1620617795569; Sun, 09 May 2021 20:36:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620617795; cv=none; d=google.com; s=arc-20160816; b=iFL3pAR/xsuYw8s+AuninILU+UfbDopNwinl64e3xGpOBW803DQOEWkkE6nIzcF6tk IDvt2DekqraiEZNZXVgMLwXrVw9en5Rw6MiyVdYMjUAjq8jjhvyO0h4qGLGW8bP5NG0F yBHgcYXe9372DggpWyg2XgQ//VXKkDcYZO/P0nf8LEsk7xmIZaqnW6f8dEE/3pBlJCPE MSw65IANuxyeeqcg+MN3d/MjuWGRJQluGDLyVw9fe9Nh6DlxDLpmQXM7hBmCGU6M5A68 CjKJYqa9nmvCrKS5DSMrYLezpkPoscM9MEuKYrTYdV7P4m2A8MOKdRFIdEJnYJ9Mb19D htxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=YmiL5sZt6y3FQ9bFsxg5j6M50MOeMtsJGnKPhpPk3hk=; b=HOf6bXGxWigXoXxuhA/hUvsRaTuv41QK0winD5UViPq9GswwmlslCyXI5C2qeNZzXw mhB4asx3AAWvrotYCNQSuJ6RX8ydRZ3Ff/I1iHgCdiWY47mxzMNPsYFX6EFfTA86ACJc KfI9SIX6ybJTYT+UqMoy8vARZP2Tn9vgtjaPtuti5/Ium1/bnHJ/ukcP9x9kOLXhLKxM v9OLZowfL7my5b7yjbP+o45QzbbQ+RtI8Nx60p1enpB4xRvO3YgsuyLLMy60+shOFmyq 5jrNKZvz2Rh4merDtP020clWqro351mOCzqjZJRgsc8Vo7BIJGjFt2px7LUMhkmR2KUN 8q3g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z13si8088278ilu.28.2021.05.09.20.36.15; Sun, 09 May 2021 20:36:35 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230129AbhEJDhM (ORCPT + 99 others); Sun, 9 May 2021 23:37:12 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:2608 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230127AbhEJDhM (ORCPT ); Sun, 9 May 2021 23:37:12 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Fdmqm1cWpzlcrQ; Mon, 10 May 2021 11:33:56 +0800 (CST) Received: from [127.0.0.1] (10.174.177.249) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Mon, 10 May 2021 11:36:00 +0800 Subject: Re: [PATCH] e2fsprogs: Try again to solve unreliable io case From: Zhiqiang Liu To: Theodore Ts'o CC: Haotian Li , Ext4 Developers List , "harshad shirwadkar," , linfeilong References: <6bc8c1c2-9fff-bef9-c6f3-b2256a4888e1@huawei.com> Message-ID: Date: Mon, 10 May 2021 11:35:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <6bc8c1c2-9fff-bef9-c6f3-b2256a4888e1@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.174.177.249] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org friendly ping ... On 2021/4/24 12:46, Zhiqiang Liu wrote: > > On 2021/4/23 23:46, Theodore Ts'o wrote: >> On Fri, Apr 23, 2021 at 10:18:09AM +0800, Zhiqiang Liu wrote: >>> Thanks for your reply. >>> Actually, we have met the problem in ipsan situation. >>> When exec 'fsck -a ', short-term fluctuations or >>> abnormalities may occur on the network. Despite the driver has >>> do the best effort, some IO errors may occur. So add retrying in >>> e2fsprogs can further improve the reliability of the repair >>> process. >> But why doesn't this happen when the file system is mounted, and why >> is that acceptable? And why not change the driver to do more retries? >> >> - Ted >> > Actually, this may happen when the filesystem is mounted. The difference > is that the mounted filesystem can ensure the consistency with journal. > > For example, if the IO error occurs when calling io_channel_write_byte() > to update superblock, the checksum may be not written to the disk successfully. > Then the checksum error will occur, and the filesystem cannot be > repaired with 'fsck -y|a|f'. > > This situation has a very low probability. For improving the reliability of > the repair process, the retries in e2fsprogs may be necessary. > > Regards > Zhiqiang Liu. > >> . >> > > .