ubi vol_size and lots of bad blocks

[Artem Bityutskiy]

On Mon, 2011-10-17 at 14:35 +0100, Daniel Drake wrote:
> 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?

Well, I though that if OLPC requires some free space to boot, it could
be 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.

Yes. I was just thinking about a situation when you have so many bad
blocks, that it will be resized and there will be too few space. In that
case the device won't boot with weird and unexpected symptoms. I thought
that if you reserve min. free space, then it won't boot with predictable
symptoms - UBI will print a message like "not enough eraseblocks" or
something like that.

> 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.

Frankly, do not remember, depends on ubinize implemenation. Most
probably yes, if you put smaller number, ubinize will throw an error
back.

>  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).

Yeah, you can forget about the free space stuff.

> > 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?

Very good question. In this case you will get an error and UBI will
switch to R/O mode.

UBI guarantees that there is a PEB for each LEB. If you run out of good
PEBs, then a write to the LEB may fail.

To recover from this error you could re-flash the device. The run-time
recovery would require deleting or shrinking one of the UBI volumes.

So you need to carefully select the amount of PEBs reserver for bad
blocks handling. For Nokia phones like N900 1% was just fine. The have
Samsung OneNAND flash, 256MiB in size, 128KiB PEBs.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20111020/411d98fb/attachment.sig>