From f3acb84289e19f6b042814c63249b7fa69aacabf Mon Sep 17 00:00:00 2001 From: Richard Genoud Date: Tue, 4 Sep 2012 15:56:09 +0200 Subject: [PATCH] UBI: now we reserve 20/1024 PEB for bad block handling Signed-off-by: Richard Genoud Signed-off-by: Artem Bityutskiy --- doc/ubi.xml | 93 +++++++++++++++++++++++++++++------------------------ faq/ubi.xml | 9 ++++-- 2 files changed, 57 insertions(+), 45 deletions(-) diff --git a/doc/ubi.xml b/doc/ubi.xml index dea14e6..6bea323 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -32,6 +32,7 @@
  • Scalability issues
    • +
  • Reserved blocks for bad block handling (only for NAND chips)
  • Volume auto-resize
  • UBI operations
      @@ -516,9 +517,10 @@ amount of flash space available for UBI users. Namely:

    1. 1 PEB is reserved for wear-leveling purposes;
    2. 1 PEB is reserved for the atomic LEB change operation;
      3. -
    3. 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;
      4. +
    4. 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;
    5. 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 +530,17 @@ amount of flash space available for UBI users. Namely:

      Lets introduce symbols:

        +
      • W - total number of physical eraseblocks on the flash + chip (NB: the entire chip, 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.
      @@ -565,6 +571,10 @@ different for different flashes:

      is less than 64 bytes.
      6. +

      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).

      +

      Saving erase counters

      @@ -833,47 +843,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 -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.

      - -

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

      +(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.

      diff --git a/faq/ubi.xml b/faq/ubi.xml index 02f8146..2832928 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 chip size (20/1024 PEB) are reserved for +bad blocks handling. 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.

      -- 2.50.1