Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3063859ybf; Mon, 2 Mar 2020 22:13:35 -0800 (PST) X-Google-Smtp-Source: ADFU+vsrC6ti2smDDKUgDQ/S8lr4edSn6oS5rCwe9z5EdjF2pLnVDeh5n2yjm+QOkQXwGYpa0X1k X-Received: by 2002:a9d:70d5:: with SMTP id w21mr2274618otj.65.1583216015501; Mon, 02 Mar 2020 22:13:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583216015; cv=none; d=google.com; s=arc-20160816; b=gHeg4K6igIj3ExruUmf1z2Z0nX3omiSjkpkXNR1R6UxBeuW45rDDvWzln8HkGWTxbH RhRzhl5ndyCYBy1PEvdr1+w3NpJnYddWcHRfYwvS2azaO6toIHHofYkbZDwrNp8BhWqo f7D7V6jPnInODBLHnZZB7zRGaZQTW2nXjJsoZvVhAg8AcatVa3pOWPjvNXF7rn1IxVy3 TQc4jV5wyn2e707C9mO6ZXcPTGFKs4Q8UUxe4ZQRNQDlFV7QRCDeOZ6P4pBS0XyqTz/q Qr4dRSldL4gm+4ovLTMT+bnxOhca1v1j+JXqFzALIiaicqm23Ez3gLGgsyrEx8WKyKMt L5sw== 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:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=nbUDnaBxWD4K6wqiqcZGFFOjde+qD5rUnngbVS/+HNg=; b=HsWR22wZJmi4dQ82iSmpHV0H3TPGwTmXA/kYXdbAbvouFcBROBoyI/uINtqSEa786Q BoRGfaR33Girr6HUbhjVW29DFLDSFHQ/QxoNTrEVQyAu7mwVKuTjMrMg0DLt4XILfik0 Z1Qa1PjhSFhNWZ/bSXe8vZCR1iQelaHIfYjWUNC3eTSEPK8fw0Wlq0REVHv4ZUGoETTx ML+xC9sZkilqW1ohVn+OWpYjxSThHYxXj5/0qU3ExNfZv1R8YxadujP0aeln34DwFcLd qrZN1ySQR0Iz4qPmT0SwiMbH95v6EIrkJIgkODNuPcCckvsLo+ZkYgyGJFP3NTKAQ2nT U4kA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q7si723752otk.77.2020.03.02.22.13.22; Mon, 02 Mar 2020 22:13:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725944AbgCCGNN (ORCPT + 99 others); Tue, 3 Mar 2020 01:13:13 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:10714 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725554AbgCCGNM (ORCPT ); Tue, 3 Mar 2020 01:13:12 -0500 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 3C0997EDCB890DB2F6A6; Tue, 3 Mar 2020 14:13:09 +0800 (CST) Received: from [127.0.0.1] (10.173.221.98) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.439.0; Tue, 3 Mar 2020 14:13:00 +0800 Subject: Re: [PATCH] ubifs: Don't discard nodes in recovery when ecc err detected To: Richard Weinberger CC: Richard Weinberger , Sascha Hauer , "zhangyi (F)" , , LKML References: <1582293853-136727-1-git-send-email-chengzhihao1@huawei.com> <58b11ca2-6b91-52b3-bc75-d44abb202cfb@huawei.com> From: Zhihao Cheng Message-ID: Date: Tue, 3 Mar 2020 14:13:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.173.221.98] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/3/3 5:14, Richard Weinberger 写道: > On Mon, Mar 2, 2020 at 4:58 AM Zhihao Cheng wrote: >> I mean, the uncorrectable ECC error is caused by hardware which may lead >> to corrupted nodes detected in UBIFS. I found uncorretable ECC errors on >> my NAND, in the environment of high temperature and humidity. >> >> At present, UBIFS ignores all EBADMSG errors, so the corrupted node is >> only considered in being caused by unfinished writing. I think UBIFS >> should consider the corrupted area caused by ECC errors in process >> ubifs_recover_leb(). no_more_nodes() will skip a read-write unit. Maybe >> the corrupted area is skipped. > Well, if your NAND data is corrupted by your environment UBIFS cannot > do much. Sure, we can paper over some places but at the end of the day > you will always lose. > > What if the UBI VID header becomes unreadable or the root node of the > index tree? > Agree, thanks for reminding.