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

Richard Genoud richard.genoud at gmail.com
Tue Sep 4 10:01:07 EDT 2012


2012/9/4 Richard Genoud <richard.genoud at gmail.com>:
> +
> +<h2><a name="L_autoresize">Volume auto-resize</a></h2>
>
>  <p>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.</p>
> -
> -<p>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).</p>
> -
> -<p>But there is an alternative approach - one of the volume may have the
> -<b>auto-resize</b> 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.</p>
> +
> +<p>That what the auto-resize is about. If the volume has the <b>auto-resize</b>
> +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.</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 2% of
> -PEBs will anyway be reserved for bad PEB handling.</p>
> +stored in the volume table and only one volume may be marked as auto-resize.</p>
>
>  <p>Note, the auto-resize feature exists in the Linux kernel starting from
>  version <code>2.6.25</code>.</p>
I change this because I think there was a misunderstanding, the
manufacturer guarantees that there won't be more than xxx bad block on
the device during its "endurance lifetime" not at shipping time.
So I gave another example, but fill free to change it !

Best regards,
Richard.



More information about the linux-mtd mailing list