confusion UBI overhead and volume size calculations

confusion UBI overhead and volume size calculations

[twebb]

I'm very confused about the calculations for determining max-leb-cnt
argument for mkfs.ubifs and vol_size for ubinize cfg file.

I have a 4GiB MLC nand device that has a 64M reserved area from
0x0-0x04000000.  The rest, 0x04000000-0x100000000 (4032M), is
dedicated to a single MTD partition.  A single UBI device will attach
to the single MTD partition and have 4 volumes.  I'm using mkfs.ubifs
and ubinize at build time to create a single UBI image to be flashed
to the MTD device.

The four volumes are...
vol1 = 352M
vol2 = 352M
vol3 = 352M
vol4 = 2976M

The device data sheet specifies that the minimum valid block count is
7992 (of 8192 possible), so it seems like I should reserve 200 blocks
(100M) to allow for this.

My questions are:
1.  How does the 100M reserved for "potentially bad blocks" get
handled when calculating the vol_size for each volume in the .cfg
file?  I'd like to leave vol1-3 intact and only take space from vol4.
Would the vol_sizes be as follows?

vol1 vol_size = 352M
vol2 vol_size = 352M
vol3 vol_size = 352M
vol4 vol_size = 2976M-100M = 2876M


2.  How is the overhead calculation from the linux-mtd site used in
determining the vol_sizes?  ("The UBI overhead is (B + 4) * SP + O *
(P - B - 4) i.e., this amount of bytes will not be accessible for
users.")

3.  Is max-leb-cnt simple the vol_size/LEB_size?

I'm really lost on this.  I'd appreciate any input anyone may have on this.

Thanks,
twebb

Re: confusion UBI overhead and volume size calculations

[Adrian Hunter]

twebb wrote:
> I'm very confused about the calculations for determining max-leb-cnt
> argument for mkfs.ubifs and vol_size for ubinize cfg file.
> 
> I have a 4GiB MLC nand device that has a 64M reserved area from
> 0x0-0x04000000.  The rest, 0x04000000-0x100000000 (4032M), is
> dedicated to a single MTD partition.  A single UBI device will attach
> to the single MTD partition and have 4 volumes.  I'm using mkfs.ubifs
> and ubinize at build time to create a single UBI image to be flashed
> to the MTD device.
> 
> The four volumes are...
> vol1 = 352M
> vol2 = 352M
> vol3 = 352M
> vol4 = 2976M
> 
> The device data sheet specifies that the minimum valid block count is
> 7992 (of 8192 possible), so it seems like I should reserve 200 blocks
> (100M) to allow for this.
> 
> My questions are:
> 1.  How does the 100M reserved for "potentially bad blocks" get
> handled when calculating the vol_size for each volume in the .cfg
> file?  I'd like to leave vol1-3 intact and only take space from vol4.
> Would the vol_sizes be as follows?
> 
> vol1 vol_size = 352M
> vol2 vol_size = 352M
> vol3 vol_size = 352M
> vol4 vol_size = 2976M-100M = 2876M
> 
> 

You must tell UBI that you want the last volume automatically resized
to fit the available space.

This is covered in the documentation:

http://linux-mtd.infradead.org/doc/ubi.html#L_autoresize


> 2.  How is the overhead calculation from the linux-mtd site used in
> determining the vol_sizes?  ("The UBI overhead is (B + 4) * SP + O *
> (P - B - 4) i.e., this amount of bytes will not be accessible for
> users.")
> 
> 3.  Is max-leb-cnt simple the vol_size/LEB_size?

max-leb-cnt stands for maximum LEB count.  It is the maximum number of
LEBs that UBIFS will use.  It must be more than the number of LEBs you
will ever have.  So the number of PEBs is a reasonable choice, although
it also makes sense to round up to a power of 2.  For example:

352M => 704 PEBS @ 512K / PEB => max_leb_cnt=1024 is a good choice

2976M => 5952 PEBS @ 512K / PEB => max_leb_cnt=8192 is a good choice


There is some documentation here:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt

Re: confusion UBI overhead and volume size calculations

[Artem Bityutskiy]

Hello,

On Mon, 2009-12-21 at 10:57 -0500, twebb wrote:
> I'm very confused about the calculations for determining max-leb-cnt
> argument for mkfs.ubifs and vol_size for ubinize cfg file.
> 
> I have a 4GiB MLC nand device that has a 64M reserved area from
> 0x0-0x04000000.  The rest, 0x04000000-0x100000000 (4032M), is
> dedicated to a single MTD partition.  A single UBI device will attach
> to the single MTD partition and have 4 volumes.  I'm using mkfs.ubifs
> and ubinize at build time to create a single UBI image to be flashed
> to the MTD device.

Sounds OK, except that UBI / UBIFS might not be fully MLC-ready, see
here: http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc

> The four volumes are...
> vol1 = 352M
> vol2 = 352M
> vol3 = 352M
> vol4 = 2976M

There is some UBI overhead. It reserves 2 PEBs for the volume table,
some amount for bad block handling (defaults to 1%), etc. This is
described here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_overhead

So basically UBI will take about 4 + 0.01 * 8064 = 85 PEBs, where
8064 PEBs comes from your 4032MiB / 512KiB.

Note, this 1% is taken from the amount of _good_ PEBs. 8064 is when
there are no bad PEBs at all, so this is the absolute maximum number.

> The device data sheet specifies that the minimum valid block count is
> 7992 (of 8192 possible), so it seems like I should reserve 200 blocks
> (100M) to allow for this.

Here we talk about factory-marked bad PEBs. Your data sheet specifies
that a new NAND chip will have 0-200 bad blocks.

It is important to understand that UBI will reserve 1% of good PEBs
anyway. It does not matter how many factory-marked bad PEBs you have.

But for MLC 1% is probably too small. This default was selected for SLC.
However, I've never worked with real raw MLC NAND flashes, so I do not
know.

Anyway, you have a dilemma of how big vol4 has to be. The answer is - of
course you should count only on minimum amount of good PEBs, i.e. 7864. 

> My questions are:
> 1.  How does the 100M reserved for "potentially bad blocks" get
> handled when calculating the vol_size for each volume in the .cfg
> file?  I'd like to leave vol1-3 intact and only take space from vol4.
> Would the vol_sizes be as follows?
> 
> vol1 vol_size = 352M
> vol2 vol_size = 352M
> vol3 vol_size = 352M
> vol4 vol_size = 2976M-100M = 2876M

Not exactly. You specify volume size in megabytes. Your PEB size is
512KiB, but LEB size will be smaller because of UBI headers. I do not
know your NAND flash's page size. But if it is 4KiB, LEB size will be
512KiB - 8KiB = 504KiB. This means that 352MiB of the "UBI space" will
"eat" 716 PEBs, not 704 PEBs as you calculated.

Let's re-calculate.

1. Your have 8064 PEBs.
2. Your LEB size is 504KiB. This basically means that each your PEB
gives you 504KiB of "UBI space", not 512KiB.
3. Your flash can have up to 200 factory-marked bad PEBs. This means
that in the worst case your will have 7864 PEBs.
4. UBI will reserve 4 + 0.01 * 7864 ~ 83 PEBs, this means that you will
actually have only 7781 PEBs for your needs.
5. You want vol1 to be 352MiB, this is about 352MiB / 504KiB ~ 716PEBs.
6. So for vol1 - vol3 you will "spend" 716 * 3 = 2148PEBs.
7. And now you have 7781 - 2148 = 5633 PEBs left for vol4.
8. 5633 PEBs will give you about 5633 * 504KiB ~ 2772MiB of "UBI space".
9. This means for vol4 you will have _minimum_ 2772MiB.

You are free to similarly calculate the maximum - just drop step 3.

If my assumption about the NAND page size is wrong, you will need to
re-calculate as well.

This means you ubinize.cfg will look like this (not testes! can contain
mistakes!):

[volume1]
mode=ubi
image=vol1.img
vol_id=0
vol_size=352MiB
vol_type=dynamic
vol_name=vol1

[volume2]
mode=ubi
image=vol2.img
vol_id=1
vol_size=352MiB
vol_type=dynamic
vol_name=vol2

[volume3]
mode=ubi
image=vol3.img
vol_id=2
vol_size=352MiB
vol_type=dynamic
vol_name=vol3

[volume4]
mode=ubi
image=vol4.img
vol_id=3
vol_size=2772MiB
vol_type=dynamic
vol_name=vol4
vol_flags=autoresize

See: http://www.linux-mtd.infradead.org/faq/ubi.html#L_ubi_mkimg

This means that all your devices will have vol4 of exactly the same
size. And because most of the chips will have much less than 200
factory-marked bad PEBs, you will have some amount of extra available
space, which will basically be unused.

However, you may want to have fixed vol1-vol3 sizes (352MiB), and use
all the rest of the available PEBs for vol4. In this case it will be
_minimum_ 2772MiB, but in most cases a little larger (calculate
yourself).

If you do want this, use the "autoresize" flag for vol4:

vol_flags=autoresize

With the autoresize flag, when UBI attaches the flash for the first
time, it will re-size vol4 automatically to make it occupy all the
available space.

Read here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_autoresize

> 2.  How is the overhead calculation from the linux-mtd site used in
> determining the vol_sizes?  ("The UBI overhead is (B + 4) * SP + O *
> (P - B - 4) i.e., this amount of bytes will not be accessible for
> users.")

I think I have elaborated above. If you still have questions, see here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_overhead

and ask specific questions please.

> 3.  Is max-leb-cnt simple the vol_size/LEB_size?

Please, refer here:
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt

In your case, for vol1-vol3:

352MiB / 504KiB ~ 716 LEBs. And this is your max-leb-cnt.

But for UBIFS only "power-of-2" boundaries matter, this means you can
safely use max-leb-cnt = 1023. From the performance POW this will be the
same as max-leb-cnt = 716.

So, I recommend max-leb-cnt = 1023.

For vol4, your _minimum_ size is 2772MiB, so 2772MiB / 504KiB ~ 5633
LEBs. But if you use the auto-resize flag, your maximum vol4 size will
be a bit larger. Please, calculate yourself similarly.

However, you can just use max-leb-cnt = 8191.

> I'm really lost on this.  I'd appreciate any input anyone may have on this.

Yes, I can believe this stuff is confusing for newcomers. Sorry for
these complexities, exposed on you. The thing is that all this stuff is
very bound to the physical flash geometry. And because we try to work on
all kinds of flashes, you have to specify so many parameters.

P.S.: it is 00:50 here, I could make a type / mistake in my
calculations. But you should grasp the ideas.

HTH

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