UBI FS mounting time

UBI FS mounting time

[Bosi Daniele]

We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s to mount.

We'd like to have the data available at least read-only earlier than that.

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 around it to make it available earlier...

Someone know how?

Thank you.



  Daniele Bosi

Re: UBI FS mounting time

[Adrian Hunter]

Bosi Daniele wrote:
> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s to mount.
> 
> We'd like to have the data available at least read-only earlier than that.
> 
> 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 around 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 blocks.
c) Change UBI to write its mapping table when it is unloaded, so it can be read quickly when loading (still have to scan if UBI was not unloaded cleanly).

Re: UBI FS mounting time

[Corentin Chary]

On Wed, Jul 22, 2009 at 8:44 AM, Adrian Hunter<adrian.hunter@nokia.com> wrote:
> Bosi Daniele wrote:
>>
>> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s to
>> mount.
>>
>> We'd like to have the data available at least read-only earlier than that.
>>
>> 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 around
>> 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
> blocks.
> c) Change UBI to write its mapping table when it is unloaded, so it can be
> read quickly when loading (still have to scan if UBI was not unloaded
> cleanly).

Do you know if someone is trying to implement that ?
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".




-- 
Corentin Chary
http://xf.iksaif.net - http://uffs.org

RE: UBI FS mounting time

[Canella Matteo]

Adrian Hunter wrote:
> c) Change UBI to write its mapping table when it is unloaded, so it can be read quickly then loading (still have to scan if UBI was not unloaded cleanly).

This is quite interesting. Do you know if someone have already done this thing? I can't find anything about that.

Thank you
Regards
Matteo Canella

Re: UBI FS mounting time

[Adrian Hunter]

Corentin Chary wrote:
> On Wed, Jul 22, 2009 at 8:44 AM, Adrian Hunter<adrian.hunter@nokia.com> wrote:
>> Bosi Daniele wrote:
>>> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s to
>>> mount.
>>>
>>> We'd like to have the data available at least read-only earlier than that.
>>>
>>> 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 around
>>> 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
>> blocks.
>> c) Change UBI to write its mapping table when it is unloaded, so it can be
>> read quickly when loading (still have to scan if UBI was not unloaded
>> cleanly).
> 
> 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.

Re: UBI FS mounting time

[Corentin Chary]

On Wed, Jul 22, 2009 at 9:38 AM, Adrian Hunter<adrian.hunter@nokia.com> wrote:
> Corentin Chary wrote:
>>
>> On Wed, Jul 22, 2009 at 8:44 AM, Adrian Hunter<adrian.hunter@nokia.com>
>> wrote:
>>>
>>> Bosi Daniele wrote:
>>>>
>>>> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s
>>>> to
>>>> mount.
>>>>
>>>> We'd like to have the data available at least read-only earlier than
>>>> that.
>>>>
>>>> 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
>>>> around
>>>> 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
>>> blocks.
>>> c) Change UBI to write its mapping table when it is unloaded, so it can
>>> be
>>> read quickly when loading (still have to scan if UBI was not unloaded
>>> cleanly).
>>
>> 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".

-- 
Corentin Chary
http://xf.iksaif.net - http://uffs.org

RE: UBI FS mounting time

[Canella Matteo]

Just to understand if we're doing things in the right way...
we need more than 6 secs to mount 1 GB Nand Flash. 
Does this sound a normal timing?
This is the dmesg of the flash mounting:

[    6.694626] UBI: attaching mtd10 to ubi2
[    6.698594] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[    6.705712] UBI: logical eraseblock size:    126976 bytes
[    6.711154] UBI: smallest flash I/O unit:    2048
[    6.715894] UBI: sub-page size:              512
[    6.720533] UBI: VID header offset:          2048 (aligned 2048)
[    6.726564] UBI: data offset:                4096
[   12.802282] UBI: attached mtd10 to ubi2
[   12.806179] UBI: MTD device name:            "nand"
[   12.814531] UBI: MTD device size:            1024 MiB
[   12.820304] UBI: number of good PEBs:        8185
[   12.825069] UBI: number of bad PEBs:         7
[   12.829495] UBI: max. allowed volumes:       128
[   12.834144] UBI: wear-leveling threshold:    4096
[   12.838891] UBI: number of internal volumes: 1
[   12.843425] UBI: number of user volumes:     1
[   12.847860] UBI: available PEBs:             0
[   12.852325] UBI: total number of reserved PEBs: 8185
[   12.857340] UBI: number of PEBs reserved for bad PEB handling: 81
[   12.863479] UBI: max/mean erase counter: 6/3
[   12.867807] UBI: background thread "ubi_bgt2d" started, PID 911


Thank you
Regards

Matteo Canella 

Re: UBI FS mounting time

[Adrian Hunter]

Corentin Chary wrote:
> On Wed, Jul 22, 2009 at 9:38 AM, Adrian Hunter<adrian.hunter@nokia.com> wrote:
>> Corentin Chary wrote:
>>> On Wed, Jul 22, 2009 at 8:44 AM, Adrian Hunter<adrian.hunter@nokia.com>
>>> wrote:
>>>> Bosi Daniele wrote:
>>>>> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s
>>>>> to
>>>>> mount.
>>>>>
>>>>> We'd like to have the data available at least read-only earlier than
>>>>> that.
>>>>>
>>>>> 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
>>>>> around
>>>>> 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
>>>> blocks.
>>>> c) Change UBI to write its mapping table when it is unloaded, so it can
>>>> be
>>>> read quickly when loading (still have to scan if UBI was not unloaded
>>>> cleanly).
>>> 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".

I would fix the anchor block in the first good PEB and use just one.
If you lose power while erasing the anchor then you have to scan,
but you have to scan anyway if you lose power, so there is not much
difference.

Re: UBI FS mounting time

[Artem Bityutskiy]

On Wed, 2009-07-22 at 11:12 +0300, Adrian Hunter wrote:
> I would fix the anchor block in the first good PEB and use just one.
> If you lose power while erasing the anchor then you have to scan,
> but you have to scan anyway if you lose power, so there is not much
> difference.

But if you go this far, an implement the anchor things, then it makes
much more sense to implement your UBI2 ides, instead of this crippled
"dump everything to flash on unmount" stuff. Your idea of a journal
is much saner. Remember you suggested it to Samsung people as a way to
fix mount time problems, but not memory consumption issuse, which are
not that bad, and then you said we can create UBI3 to fix memory issues.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: UBI FS mounting time

[Artem Bityutskiy]

On Wed, 2009-07-22 at 11:30 +0300, Artem Bityutskiy wrote:
> On Wed, 2009-07-22 at 11:12 +0300, Adrian Hunter wrote:
> > I would fix the anchor block in the first good PEB and use just one.
> > If you lose power while erasing the anchor then you have to scan,
> > but you have to scan anyway if you lose power, so there is not much
> > difference.
> 
> But if you go this far, an implement the anchor things, then it makes
> much more sense to implement your UBI2 ides, instead of this crippled
> "dump everything to flash on unmount" stuff. Your idea of a journal
> is much saner. Remember you suggested it to Samsung people as a way to
> fix mount time problems, but not memory consumption issuse, which are
> not that bad, and then you said we can create UBI3 to fix memory issues.

BTW, you did not nicely describe it in the ML. If you can do this, I'll
put this information to the MTD web site, I think it is useful because
that sounded as a good plan.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: UBI FS mounting time

[Adrian Hunter]

Canella Matteo wrote:
> Just to understand if we're doing things in the right way...
> we need more than 6 secs to mount 1 GB Nand Flash. 
> Does this sound a normal timing?

Yes

> This is the dmesg of the flash mounting:
> 
> [    6.694626] UBI: attaching mtd10 to ubi2
> [    6.698594] UBI: physical eraseblock size:   131072 bytes (128 KiB)
> [    6.705712] UBI: logical eraseblock size:    126976 bytes
> [    6.711154] UBI: smallest flash I/O unit:    2048
> [    6.715894] UBI: sub-page size:              512
> [    6.720533] UBI: VID header offset:          2048 (aligned 2048)
> [    6.726564] UBI: data offset:                4096
> [   12.802282] UBI: attached mtd10 to ubi2
> [   12.806179] UBI: MTD device name:            "nand"
> [   12.814531] UBI: MTD device size:            1024 MiB
> [   12.820304] UBI: number of good PEBs:        8185
> [   12.825069] UBI: number of bad PEBs:         7
> [   12.829495] UBI: max. allowed volumes:       128
> [   12.834144] UBI: wear-leveling threshold:    4096
> [   12.838891] UBI: number of internal volumes: 1
> [   12.843425] UBI: number of user volumes:     1
> [   12.847860] UBI: available PEBs:             0
> [   12.852325] UBI: total number of reserved PEBs: 8185
> [   12.857340] UBI: number of PEBs reserved for bad PEB handling: 81
> [   12.863479] UBI: max/mean erase counter: 6/3
> [   12.867807] UBI: background thread "ubi_bgt2d" started, PID 911

The possibility exists to double the eraseblock size by treating 2 eraseblocks as
though it was 1.  That should halve the UBI load time to 3 seconds but it would
use a bit more memory in UBIFS.  Of course you could double again, with yet
more memory required by UBIFS.

Re: UBI FS mounting time

[Artem Bityutskiy]

On Tue, 2009-07-21 at 19:00 +0200, Bosi Daniele wrote:
> We have a UBI+UBIFS 1GB partition on a NAND chip, which takes around 6s to mount.
> 
> We'd like to have the data available at least read-only earlier than that.
> 
> 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 around it to make it available earlier...
> 
> Someone know how?

I've just created a FAQ entry where I put several ideas:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: UBI FS mounting time

[Jamie Lokier]

Corentin Chary wrote:
> 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".

You can get wear levelling of anchor blocks by using indirect anchor
blocks, where a fixed 2 blocks points to a small set of "potential"
blocks to scan at mount time - a sort of tiny journal, small enough to
scan quickly.  The bulk of data needing for mounting is stored in
those journal blocks, and the true anchor blocks in pebs 0+1 point to
the range to be scanned.

Each mount/umount cycle, one of the scanned blocks will be updated,
except every so often the true anchor blocks in pebs 0+1 will be
updated to use a new range.

That's a two-level tree.  If you make a sufficiently deep multi-level
tree using the same idea - initial small set of indirect blocks (peb
0+1 in this example) pointing to small sets of of indirect blocks
... pointing to small sets of map blocks, then you can wear level the
whole flash evenly for any number of mount/umount cycles, and still
find the mount data quickly for any flash size.

(In fact you can run a whole filesystem like that, but that's another
topic).

For additional robustness against possible clustering of bad blocks,
make the initial small set be a sparse set of pebs over the flash
address space, instead of pebs 0+1.  I'd go for maximum address line
diversity.

-- Jamie

LEB size configuration (was: UBI FS mounting time)

[Canella Matteo]

Hi Adrian, thank you for your reply,

> The possibility exists to double the eraseblock size by treating 2
> eraseblocks as
> though it was 1.  That should halve the UBI load time to 3 seconds but
> it would
> use a bit more memory in UBIFS.  Of course you could double again, with
> yet
> more memory required by UBIFS.

I'm a little bit jammed...  I surfed all the docs and faqs but I can't find the answers.
I'm trying to double the logical erase block size.
I've a 1Gb NAND flash.

Here's my steps:

Looking to the old dmesg of the flash mounting I see:
[    6.705712] UBI: logical eraseblock size:    126976 bytes

First question: Why LEB size needs to be smaller than PEB size? PEB size is 128KiB = 131072 byte. Is it mandatory to have LEB size smaller than PEB size? How much smaller?

Whatever, I try to double this value:
mkfs.ubifs  -m 2048 -e 253952 -c 4096 -o ubifs.img

the "-e" option is the LEB size (126976 * 2 = 253952)
"-c" option is the max LEB count, so I guess 4096 for 1 Gigabyte is the right number.

This is the output of the command with verbose option on:

root@mpc5121:~# mkfs.ubifs  -m 2048 -e 253952 -c 4096 -o ubifs.img -v
mkfs.ubifs
        root:         (null)
        min_io_size:  2048
        leb_size:     253952
        max_leb_cnt:  4096
        output:       ubifs.img
        jrn_size:     8388608
        reserved:     0
        compr:        lzo
        keyhash:      r5
        fanout:       8
        orph_lebs:    1
        super lebs:   1
        master lebs:  2
        log_lebs:     4
        lpt_lebs:     2
        orph_lebs:    1
        main_lebs:    3
        gc lebs:      1
        index lebs:   1
        leb_cnt:      13
        UUID:         A9CECA68-0BFB-4753-A886-3D76ADD2D067
Success!

Ok, now I have my ubifs.img
Next step: ubinize.
This is my cfg file:

root@mpc5121:~# vi ubinize.cfg

[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=992MiB
vol_type=static
vol_name=fredubifsNand
vol_alignment=1


I choose vol_size = 992Mib because 253952 (LEB size) * 4096 (N° of LEB) = 992 Mib
Ok, now launch ubinize:
root@mpc5121:~# ubinize -o ubi.img -m 2048 -p 128KiB -s 2048 ubinize.cfg -v
ubinize: LEB size:      126976
ubinize: PEB size:      131072
ubinize: min. I/O size: 2048
ubinize: sub-page size: 2048
ubinize: VID offset:    2048
ubinize: data offset:   4096
ubinize: loaded the ini-file "ubinize.cfg"
ubinize: count of sections: 1

ubinize: parsing section "ubifs"
ubinize: mode=ubi, keep parsing
ubinize: volume type: static
ubinize: volume ID: 0
ubinize: volume size: 1040187392 bytes
ubinize: volume name: fredubifsNand
ubinize: volume alignment: 1
ubinize: adding volume 0
ubinize: writing volume 0
ubinize: image file: ubifs.img

ubinize: writing layout volume
ubinize: done

Why LEB size is 126976 and not 253952 as I set up?

Now I format the MTD device (/dev/mtd10) passing ubi.img to ubiformat:

root@mpc5121:~# ubiformat /dev/mtd10 -f ubi.img -s 2048
ubiformat: mtd10 (nand), size 1073741824 bytes (1024.0 MiB), 8192 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 8191 -- 100 % complete
ubiformat: 8159 eraseblocks have valid erase counter, mean value is 9
ubiformat: bad eraseblocks: 907, 1655, 2580, 2604, 3713, 3715, 3717, 4344, 4520, 4526, 4532, 5335, 5345, 5347, 5349, 5351, 5353, 5355, 5357, 5359, 5561, 5711, 6118, 6120, 6138, 6192, 6202, 6204, 7931, 8188, 8189, 8190, 8191
ubiformat: flashing eraseblock 27 -- 100 % complete
ubiformat: formatting eraseblock 8191 -- 100 % complete


Then I try to attach the MTD device:

root@mpc5121:~# ubiattach /dev/ubi_ctrl -m 10 -O 2048
[13244.254538] UBI: attaching mtd10 to ubi0
[13244.258893] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[13244.265508] UBI: logical eraseblock size:    126976 bytes
[13244.271235] UBI: smallest flash I/O unit:    2048
[13244.276259] UBI: sub-page size:              512
[13244.281185] UBI: VID header offset:          2048 (aligned 2048)
[13244.287513] UBI: data offset:                4096
[13249.422873] UBI error: vtbl_check: volume table check failed: record 0, error 9
ubiattach: error!: cannot attach mtd10
           error 22 (Invalid argument)


Here I've got an error and the logical eraseblock size that isn't what I expected (126976 instead of 253952).

Where I'm wrong?
Thank you
Regards

Matteo Canella

Re: LEB size configuration

[Artem Bityutskiy]

On 07/22/2009 05:32 PM, Canella Matteo wrote:
> Hi Adrian, thank you for your reply,
>
>> The possibility exists to double the eraseblock size by treating 2
>> eraseblocks as
>> though it was 1.  That should halve the UBI load time to 3 seconds but
>> it would
>> use a bit more memory in UBIFS.  Of course you could double again, with
>> yet
>> more memory required by UBIFS.
>
> I'm a little bit jammed...  I surfed all the docs and faqs but I can't find the answers.
> I'm trying to double the logical erase block size.
> I've a 1Gb NAND flash.
>
> Here's my steps:
>
> Looking to the old dmesg of the flash mounting I see:
> [    6.705712] UBI: logical eraseblock size:    126976 bytes
>
> First question: Why LEB size needs to be smaller than PEB size? PEB size is 128KiB = 131072 byte. Is it mandatory to have LEB size smaller than PEB size? How much smaller?

You cannot improve your UBI attach time without doing coding,
unfortunately. If you are ready to do coding, you should really
go through UBI documentation. It answers your question.

> Whatever, I try to double this value:
> mkfs.ubifs  -m 2048 -e 253952 -c 4096 -o ubifs.img

Sorry, but you really should spend more time reading docs if you want to
improve UBI/UBIFS. From what I see you do not really distinguish between
UBI and UBIFS.

> the "-e" option is the LEB size (126976 * 2 = 253952)
> "-c" option is the max LEB count, so I guess 4096 for 1 Gigabyte is the right number.

The suggested change should be done either on MTD level, or on UBI level.
The FAQ entry I wrote for you briefly explains how one could do this on
UBI level.

...
> Here I've got an error and the logical eraseblock size that isn't what I expected (126976 instead of 253952).

Yes, you have created UBIFS image for larger LEB, but UBI does not support
it, so you see errors because of that disagreement.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

RE: LEB size configuration

[Canella Matteo]

Hi Artem, thanks for your quick reply,

> You cannot improve your UBI attach time without doing coding,
> unfortunately. If you are ready to do coding, you should really
> go through UBI documentation. It answers your question.

I've misunderstood Adrian's answer.
I thought it was possible to double LEB size without modifying UBI layer.
I'll take a deeper look at the documentation.

Thank you
Regards
Matteo Canella

Re: LEB size configuration

[Artem Bityutskiy]

On 07/22/2009 06:12 PM, Canella Matteo wrote:
> Hi Artem, thanks for your quick reply,
>
>> You cannot improve your UBI attach time without doing coding,
>> unfortunately. If you are ready to do coding, you should really
>> go through UBI documentation. It answers your question.
>
> I've misunderstood Adrian's answer.
> I thought it was possible to double LEB size without modifying UBI layer.

Well, when you or someone else implement this, it will be possible :-)

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)