From 2b91234cf1dd9968d18679b19d7dbe22b6508cff Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Mon, 16 Jul 2012 18:28:03 +0300 Subject: [PATCH] UBI: now we reserve 2% of PEBs for bad eraseblock handling Signed-off-by: Artem Bityutskiy --- doc/ubi.xml | 10 +++++----- faq/ubi.xml | 11 ++--------- 2 files changed, 7 insertions(+), 14 deletions(-) diff --git a/doc/ubi.xml b/doc/ubi.xml index 98cb69c..dea14e6 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -518,7 +518,7 @@ amount of flash space available for UBI users. Namely:

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 1% by default;
    • + reserved PEBs is configurable and is 2% 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 @@ -533,7 +533,7 @@ amount of flash space available for UBI users. Namely:

  • SP - physical eraseblock size;
  • SL - logical eraseblock size;
  • B - number of PEBs reserved for bad PEB handling; it is - 1% of P for NAND by default, and 0 for NOR and other flash types + 2% of P for NAND by default, and 0 for NOR and other flash types which do not have bad PEBs;
  • O - the overhead related to storing EC and VID headers in bytes, i.e. O = SP - SL.
    • @@ -855,8 +855,8 @@ 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 1% of PEBs by default. So in case of -the above mentioned OneNAND chip the result would be that 1% of PEBs would be +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).

    @@ -869,7 +869,7 @@ 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 1% of +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 diff --git a/faq/ubi.xml b/faq/ubi.xml index fa988ed..22b46e2 100644 --- a/faq/ubi.xml +++ b/faq/ubi.xml @@ -459,17 +459,10 @@ must be an issue for UBI as well.

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

    -By default, 1% of the available PEBs are reserved for handling bad blocks. +By default, 2% of the available PEBs are reserved for handling bad blocks. If the number of blocks that turn bad exceeds that allocation, an error -will be presented and UBI will switch to read-only mode. - -To recover from this error you could re-flash the device. The run-time -recovery would require deleting or shrinking one of the UBI volumes. - -So, you need to carefully select the amount of PEBs reserved for bad -blocks handling. For Nokia phones like N900 (with Samsung OneNAND flash, -256MiB in size, 128KiB PEBs) 1% was just fine. +message will be printed and UBI will switch to read-only mode. -- 2.49.0