UBI FS mounting time
corentin.chary at gmail.com
Wed Jul 22 03:57:33 EDT 2009
On Wed, Jul 22, 2009 at 9:38 AM, Adrian Hunter<adrian.hunter at nokia.com> wrote:
> Corentin Chary wrote:
>> On Wed, Jul 22, 2009 at 8:44 AM, Adrian Hunter<adrian.hunter at nokia.com>
>>> Bosi Daniele wrote:
>>>> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s
>>>> We'd like to have the data available at least read-only earlier than
>>>> We know UBI on principle needs to read the map of all blocks in order to
>>>> rebuild the logical view of the memory, but maybe there's another way
>>>> it to make it available earlier...
>>>> Someone know how?
>>> Some options are:
>>> a) Use another smaller partition that can mount first and provide some
>>> functionality while the larger partition mounts.
>>> b) Reduce the number of eraseblocks by combining them into larger logical
>>> c) Change UBI to write its mapping table when it is unloaded, so it can
>>> read quickly when loading (still have to scan if UBI was not unloaded
>> Do you know if someone is trying to implement that ?
> Not that particular approach. Some Samsung people have looked at
> creating a scalable version of UBI.
>> I did some test, and using lzo/zlib it should be possible to store
>> such a mapping
>> store in only one PEB.
>> Then we can choose this PEB to be near the beginning of the
>> flash to speed up scanning (using ec and pnum to calculate a "score").
>> This is also possible to use an "anchor".
> Yes, it is better to use anchor blocks. Probably just one is enough if
> it is only updated twice per mount.
Do you think it would be better to fix the position of the anchor
(first 2 good peb,
ideally 0 and 1), or try to get a "good" position using ec and pnum ?
With a fixed position at the beginning, the scan process would be easier,
because there is no need to reset if we find the anchor after normal blocks.
But is does not sound very "wear leveling".
http://xf.iksaif.net - http://uffs.org
More information about the linux-mtd