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;

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

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.

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