From patchwork Sun Feb 6 17:39:12 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 82060 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 30771B70A9 for ; Mon, 7 Feb 2011 04:39:01 +1100 (EST) Received: from canuck.infradead.org ([2001:4978:20e::1]) by bombadil.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pm8Y2-0003Ya-7h; Sun, 06 Feb 2011 17:37:18 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Pm8Y0-00020F-Ng; Sun, 06 Feb 2011 17:37:16 +0000 Received: from smtp.nokia.com ([147.243.1.48] helo=mgw-sa02.nokia.com) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pm8Xb-0001xQ-Om for linux-mtd@lists.infradead.org; Sun, 06 Feb 2011 17:36:55 +0000 Received: from eru.research.nokia.com (esdhcp034110.research.nokia.com [172.21.34.110]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p16Han8C014624 for ; Sun, 6 Feb 2011 19:36:50 +0200 From: Artem Bityutskiy To: "linux-mtd@lists.infradead.org" Subject: [PATCH 4/5] UBI: cleanup comments about corrupted PEBs Date: Sun, 6 Feb 2011 19:39:12 +0200 Message-Id: <1297013953-28886-5-git-send-email-dedekind1@gmail.com> X-Mailer: git-send-email 1.7.2.3 In-Reply-To: <1297013953-28886-1-git-send-email-dedekind1@gmail.com> References: <1297013953-28886-1-git-send-email-dedekind1@gmail.com> X-Nokia-AV: Clean X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110206_123652_301538_36654942 X-CRM114-Status: GOOD ( 20.26 ) X-Spam-Score: 3.4 (+++) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (3.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is freemail (dedekind1[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 2.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Artem Bityutskiy Just make them a bit more readable and explanatory. Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/scan.c | 54 ++++++++++++++++++++++++++++++----------------- 1 files changed, 34 insertions(+), 20 deletions(-) diff --git a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c index 0028bf2..b65cc08 100644 --- a/drivers/mtd/ubi/scan.c +++ b/drivers/mtd/ubi/scan.c @@ -39,32 +39,46 @@ * eraseblocks are put to the @free list and the physical eraseblock to be * erased are put to the @erase list. * + * About corruptions + * ~~~~~~~~~~~~~~~~~ + * + * UBI protects EC and VID headers with CRC-32 checksums, so it can detect + * whether the headers are corrupted or not. Sometimes UBI also protects the + * data with CRC-32, e.g., when it executes the atomic LEB change operation, or + * when it moves the contents of a PEB for wear-leveling purposes. + * * UBI tries to distinguish between 2 types of corruptions. - * 1. Corruptions caused by power cuts. These are harmless and expected - * corruptions and UBI tries to handle them gracefully, without printing too - * many warnings and error messages. The idea is that we do not lose - * important data in these case - we may lose only the data which was being - * written to the media just before the power cut happened, and the upper - * layers (e.g., UBIFS) are supposed to handle these situations. UBI puts - * these PEBs to the head of the @erase list and they are scheduled for - * erasure. + * + * 1. Corruptions caused by power cuts. These are expected corruptions and UBI + * tries to handle them gracefully, without printing too many warnings and + * error messages. The idea is that we do not lose important data in these case + * - we may lose only the data which was being written to the media just before + * the power cut happened, and the upper layers (e.g., UBIFS) are supposed to + * handle such data losses (e.g., by using the FS journal). + * + * When UBI detects a corruption (CRC-32 mismatch) in a PEB, and it looks like + * the reason is a power cut, UBI puts this PEB to the @erase list, and all + * PEBs in the @erase list are scheduled for erasure later. * * 2. Unexpected corruptions which are not caused by power cuts. During - * scanning, such PEBs are put to the @corr list and UBI preserves them. - * Obviously, this lessens the amount of available PEBs, and if at some - * point UBI runs out of free PEBs, it switches to R/O mode. UBI also loudly - * informs about such PEBs every time the MTD device is attached. + * scanning, such PEBs are put to the @corr list and UBI preserves them. + * Obviously, this lessens the amount of available PEBs, and if at some point + * UBI runs out of free PEBs, it switches to R/O mode. UBI also loudly informs + * about such PEBs every time the MTD device is attached. * * However, it is difficult to reliably distinguish between these types of - * corruptions and UBI's strategy is as follows. UBI assumes (2.) if the VID - * header is corrupted and the data area does not contain all 0xFFs, and there - * were not bit-flips or integrity errors while reading the data area. Otherwise - * UBI assumes (1.). The assumptions are: - * o if the data area contains only 0xFFs, there is no data, and it is safe - * to just erase this PEB. - * o if the data area has bit-flips and data integrity errors (ECC errors on + * corruptions and UBI's strategy is as follows. UBI assumes corruption type 2 + * if the VID header is corrupted and the data area does not contain all 0xFFs, + * and there were no bit-flips or integrity errors while reading the data area. + * Otherwise UBI assumes corruption type 1. So the decision criteria are as + * follows. + * o If the data area contains only 0xFFs, there is no data, and it is safe + * to just erase this PEB - this is corruption type 1. + * o If the data area has bit-flips or data integrity errors (ECC errors on * NAND), it is probably a PEB which was being erased when power cut - * happened. + * happened, so this is corruption type 1. However, this is just a guess, + * which might be wrong. + * o Otherwise this it corruption type 2. */ #include