ubi vol_size and lots of bad blocks

[Daniel Drake]

Hi Artem,

Thanks for the detailed response - I'll be sure to send another
documentation patch once we've got to the bottom of everything.

On Fri, Oct 14, 2011 at 12:15 PM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
>> I found a note in the UBI FAQ where it says vol_size can be excluded
>> and it will be computed to be the size of the input image, and then
>> the autoresize flag can be used to expand the partition later.
>> Excluding vol_size in this way indeed solves the problem and the
>> problematic laptop now boots.
>
> Well, you probably need some free space as well. Just come up with
> some minimum number, say 300MiB and use this number for volume size in
> ubinize, and use autoresize flag.

Regarding free space, is it really necessary? My understanding is that
the autoresize functionality will resize the volume *before* it gets
mounted for the first time, so it should be fine to not leave any free
space at image creation time. When it gets mounted for the first time,
it will be freshly resized and have free space available.

As for "some minimum number", I guess it goes without saying that
whatever number is chosen, it must be bigger than the amount of data
that is going to be written into the image. Our image building tool
will be used by different customers who will apply simple
customisations (e.g. with GNOME, with wikipedia) so the range of image
sizes varies. We need to do it based on some kind of calculation that
considers the size of the initial data to be written to the flash. If
we can do it with no free space initially, we can let ubinize do that
for us, with autoresize enabled (this was my trail of thought).

> Autorisize will not occupy the PEBs reserved for bad block handling.

OK, thanks for clarifying.
One final question... What happens when the PEBs reserved for bad
block handling run out?

Thanks,
Daniel