UBI: now we reserve 2% of PEBs for bad eraseblock handling

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

diff --git a/doc/ubi.xml b/doc/ubi.xml
index 98cb69cd314371bac2b3743d0170235a57eb4b31..dea14e66fe044520d448c206d031cea173d9cce5 100644 (file)
--- a/doc/ubi.xml
+++ b/doc/ubi.xml
@@ -518,7 +518,7 @@ amount of flash space available for UBI users. Namely:</p>
        <a href="ubi.html#L_lebchange">atomic LEB change</a> operation;</li>
        <li>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;</li>
+       reserved PEBs is configurable and is 2% by default;</li>
        <li>UBI stores the EC and VID
        <a href="ubi.html#L_ubi_headers">headers</a> 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:</p>
        <li><i>S<sub>P</sub></i> - physical eraseblock size;</li>
        <li><i>S<sub>L</sub></i> - logical eraseblock size;</li>
        <li><i>B</i> - number of PEBs reserved for bad PEB handling; it is
-       1% of <i>P</i> for NAND by default, and 0 for NOR and other flash types
+       2% of <i>P</i> for NAND by default, and 0 for NOR and other flash types
        which do not have bad PEBs;</li>
        <li><i>O</i> - the overhead related to storing EC and VID headers in
        bytes, i.e. <i>O</i> = <i>S<sub>P</sub></i> - <i>S<sub>L</sub></i>.</li>
@@ -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).</p>
 
@@ -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.</p>
 
 <p>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.</p>
 
 <p>Note, the auto-resize feature exists in the Linux kernel starting from

diff --git a/faq/ubi.xml b/faq/ubi.xml
index fa988eda8ef581503803b20a0df44c9a6422c103..22b46e2bf20fdd47b4ba289be053beb086a395ed 100644 (file)
--- a/faq/ubi.xml
+++ b/faq/ubi.xml
@@ -459,17 +459,10 @@ must be an issue for UBI as well.</p>
 
 <h2><a name="L_bad_blocks_exceeded">What happens when the PEBs reserved for bad block handling run out?</a></h2>
 
-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.