[MTD website] UBI: now we reserve 20/1024 PEB for bad block handling

Richard Genoud
2012-09-04T13:56:24Z

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
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.

--
1.7.2.5