From patchwork Tue Sep 4 13:56:09 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Genoud X-Patchwork-Id: 181565 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 86A622C008C for ; Tue, 4 Sep 2012 23:58:05 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1T8tcA-0007ri-3H; Tue, 04 Sep 2012 13:56:26 +0000 Received: from mail-wg0-f49.google.com ([74.125.82.49]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1T8tc7-0007rU-97 for linux-mtd@lists.infradead.org; Tue, 04 Sep 2012 13:56:24 +0000 Received: by wgbdt14 with SMTP id dt14so3557122wgb.18 for ; Tue, 04 Sep 2012 06:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer; bh=lfZD9sWsOsOGp6c6seRuTQMu8k/Gg0fyVgIvGEO8+RI=; b=tD+m43TnctdmN98RuatXJPaCDoxPPL6z+A1JbGBRiVDBneI2X2vuanpmSQDFcr59Qs GweeGgJXwRw3PZG92fhwiNw8uPkV5Y8mdIgjZjnUOlAVppeN1Z9ARGxJF6z3WPwmnjwY ouzVlbh1xm5YYBn/5UZ0NgTDqKLibYAs0LAKW//Knlo+uSAVBQSKMNEoj1rEflDi0x/0 qAUeaGP9IfGi92C3nVSFiRp9fPBsnVS7EKxU2yJQ+gj3qjWvLnSj0U/8TZxhMo13TAR0 hE2LuReGIp27jejwb/KBCCjIpbfgsQfFDnTVWhomxrDDxh0d6kpqLG+suO/vzO7J6r4y FM0A== Received: by 10.180.91.132 with SMTP id ce4mr30961552wib.17.1346766979650; Tue, 04 Sep 2012 06:56:19 -0700 (PDT) Received: from localhost.localdomain (lyon.paratronic.fr. [213.41.177.106]) by mx.google.com with ESMTPS id h9sm24529195wiz.1.2012.09.04.06.56.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 06:56:18 -0700 (PDT) From: Richard Genoud To: Artem Bityutskiy Subject: [MTD website] UBI: now we reserve 20/1024 PEB for bad block handling Date: Tue, 4 Sep 2012 15:56:09 +0200 Message-Id: <1346766969-13490-1-git-send-email-richard.genoud@gmail.com> X-Mailer: git-send-email 1.7.2.5 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.49 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (richard.genoud[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Richard Genoud , linux-mtd@lists.infradead.org, Shmulik Ladkani X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 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 Signed-off-by: Richard Genoud --- doc/ubi.xml | 84 +++++++++++++++++++++++++++++++++-------------------------- faq/ubi.xml | 9 ++++-- 2 files changed, 53 insertions(+), 40 deletions(-) diff --git a/doc/ubi.xml b/doc/ubi.xml index dea14e6..90a9508 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -516,9 +516,10 @@ amount of flash space available for UBI users. Namely:

  • 1 PEB is reserved for wear-leveling purposes;
  • 1 PEB is reserved for the atomic LEB change operation;
    • -
  • some amount of PEBs is reserved for bad PEB handling; this is - applicable for NAND flash, but not for NOR flash; the percentage of - reserved PEBs is configurable and is 2% by default;
    • +
  • some amount of PEBs is reserved + for bad PEB handling; this is applicable for NAND flash, but not for + NOR flash; the amount of reserved PEBs is configurable and is equal + to 20 blocks per 1024 blocks by default;
  • UBI stores the EC and VID headers at the beginning of each PEB; the amount of bytes used for these purposes depends on the flash @@ -528,13 +529,17 @@ amount of flash space available for UBI users. Namely:

    Lets introduce symbols:

      +
    • W - total number of physical eraseblocks on the flash + device (NB: the whole device, not the MTD partition);
    • P - total number of physical eraseblocks on the MTD - device;
      • + partition);
    • SP - physical eraseblock size;
    • SL - logical eraseblock size;
      • -
    • B - number of PEBs reserved for bad PEB handling; it is - 2% of P for NAND by default, and 0 for NOR and other flash types - which do not have bad PEBs;
      • +
    • BB - number of bad blocks on the MTD partition;
      • +
    • BR - number of PEBs reserved for bad PEB + handling. it is 20 * W/1024 for NAND by default, and 0 for NOR + and other flash types which do not have bad PEBs;
      • +
    • B - MAX(BR,BB);
    • O - the overhead related to storing EC and VID headers in bytes, i.e. O = SP - SL.
    @@ -564,6 +569,9 @@ different for different flashes:

    64 bytes aligned to the min. I/O unit size if the min. I/O unit size is less than 64 bytes.
    • +

    N.B.: the formula above counts bad blocks as a UBI overhead. The real +UBI overhead is: (B - BB + 4) * SP + +O * (P - B - 4)

    @@ -833,44 +841,46 @@ UBI.

    -

    Volume auto-resize

    +

    Reserved blocks for bad block handling (only for NAND chips)

    It is well-known that NAND chips have some amount of physical eraseblocks -marked as bad by the manufacturer. The bad PEBs are distributed randomly -and their number is different, although manufacturers usually guarantee that +marked as bad by the manufacturer. During the lifetime of the NAND device, +other bad blocks may appear. Although, manufacturers usually guarantee that the first few physical eraseblocks are not bad and the total amount of bad PEBs -does not exceed certain number. For example, a new 256MiB Samsung OneNAND chip -is guaranteed to have not more than 40 128KiB PEBs (but of course, more -physical eraseblock will become bad over time). This is about 2% of flash -size.

    +will not exceed certain number. For example, a 256MiB (2048 128KiB PEBs) +Samsung OneNAND chip is guaranteed to have not more than 40 128KiB PEBs during +its endurance lifetime. This is a very common value for NAND devices: +20/1024 PEB, which is about 2% of flash size.

    + +

    This ratio of 20/1024 is the default number of blocks that UBI reserves for +a UBI device. It means that if there's 2 UBI devices on a 4096 PEB NAND, 80 PEB +for each UBI device will be reserved. This may appear as a waste of +space, but as far as bad blocks can appear everywhere on the NAND flash, and +are not equally disposed on the whole device, it's the safer way. So instead of +using several UBI devices on a NAND flash, it's more space efficient to use only +one UBI device and several UBI volumes.

    +

    The default value of 20 PEB reserved per 1024 PEB is a kernel config option. +For each UBI device, this value can be adjusted via a kernel parameter or an +ubiattach parameter (since kernel 3.7).

    + + + + +

    Volume auto-resize

    When it is needed to create an UBI image which will be flashed to the end user devices in production line, you should define exact sizes of all volumes -(the sizes are stored in the UBI volume table). But it is difficult to do -because the total flash chip size may vary depending on the amount of the -initially bad PEBs.

    - -

    One obvious way to solve the problem is to assume the worst case, when all -chips would have maximum amount of bad PEBs. But in practice, most of the chips -will have only few bad PEBs which is far less than the maximum. In general, it -is fine - this will increase reliability, because UBI anyway uses all PEBs of -the device. On the other hand UBI anyway reserves some amount of physical -eraseblocks for bad PEB handling which is 2% of PEBs by default. So in case of -the above mentioned OneNAND chip the result would be that 2% of PEBs would be -reserved by UBI, and 0-2% of PEBs would not be used (they would be seen as -available LEBs to the UBI users).

    - -

    But there is an alternative approach - one of the volume may have the -auto-resize mark, which means that its size has to be enlarged when UBI +(the sizes are stored in the UBI volume table). But usually, in the embedded +world, we like to have one (read only) volume for the root file system and +one read write volume for the rest (logs, user data, etc.). If the size of the +root file system is fixed, the size of the second one can vary from one product +to another (different flash sizes) and we just want all space left.

    + +

    That what the auto-resize is about. If the volume has the auto-resize +mark, its size will be enlarged when UBI is run for the first time. After the volume size is adjusted, UBI removes the auto-resize mark and the volume is not re-sized anymore. The auto-resize flag is -stored in the volume table and only one volume may be marked as auto-resize. -For example, if there is a volume which is intended to have the root -file-system, it may be reasonable to mark it with the auto-resize flag.

    - -

    In the example with OneNAND chip, if one of the UBI volumes is be marked -as auto-re-sized, it will be enlarged by 0-2% on the first UBI boot, but 2% of -PEBs will anyway be reserved for bad PEB handling.

    +stored in the volume table and only one volume may be marked as auto-resize.

    Note, the auto-resize feature exists in the Linux kernel starting from version 2.6.25.

    diff --git a/faq/ubi.xml b/faq/ubi.xml index 02f8146..68aeaa4 100644 --- a/faq/ubi.xml +++ b/faq/ubi.xml @@ -459,10 +459,13 @@ must be an issue for UBI as well.

    What happens when the PEBs reserved for bad block handling run out?

    -By default, 2% of the available PEBs are reserved for handling bad blocks. - +

    By default, about 2% of the whole flash size (20/1024 PEB) are reserved for +handling bad blocks. If the number of blocks that turn bad exceeds that allocation, an error -message will be printed and UBI will switch to read-only mode. +message will be printed and UBI will switch to read-only mode.

    +

    Note: If at attach time, there's already more bad blocks than reserved PEBs, +UBI will stay in read-write mode. The switching to read-only mode only occurs +when a new bad block appears.