diff options
author | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2008-01-16 15:44:24 +0200 |
---|---|---|
committer | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2008-01-25 16:41:24 +0200 |
commit | 4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8 (patch) | |
tree | a7281874dc9298b3d7eca2d1e4cb22c326625382 /include/asm-xtensa/mman.h | |
parent | 896c0c06aa30147630e9a75949b6ae2014c841fc (diff) | |
download | op-kernel-dev-4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8.zip op-kernel-dev-4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8.tar.gz |
UBI: add auto-resize feature
The problem: NAND flashes have different amount of initial bad physical
eraseblocks (marked as bad by the manufacturer). For example, for 256MiB
Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks,
which is about 2%. When UBI is used as the base system, one needs to know
the exact amount of good physical eraseblocks, because this number is
needed to create the UBI image which is put to the devices during
production. But this number is not know, which forces us to use the
minimum number of good physical eraseblocks. And UBI additionally
reserves some percentage of physical eraseblocks for bad block handling
(default is 1%), so we have 1-3% of PEBs reserved at the end, depending
on the amount of initial bad PEBs. But it is desired to always have
1% (or more, depending on the configuration).
Solution: this patch adds an "auto-resize" flag to the volume table.
The volume which has the "auto-resize" flag will automatically be re-sized
(enlarged) on the first UBI initialization. UBI clears the flag when
the volume is re-sized. Only one volume may have the "auto-resize" flag.
So, the production UBI image may have one volume with "auto-resize"
flag set, and its size is automatically adjusted on the first boot
of the device.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'include/asm-xtensa/mman.h')
0 files changed, 0 insertions, 0 deletions