[PATCH] UBI: add minimal amount of reserved erase blocks in Kconfig

Artem Bityutskiy dedekind1 at gmail.com
Fri Jun 29 10:10:30 EDT 2012


On Fri, 2012-06-29 at 09:17 +0200, Richard Genoud wrote:
> 2012/6/28 Artem Bityutskiy <dedekind1 at gmail.com>:
> > On Thu, 2012-06-28 at 18:07 +0200, Richard Genoud wrote:
> >> Agreed, it seems that 2% of the whole flash (at least for SLC device)
> >> is more realistic.
> >
> > Agree, feel free to send a separate patch for this.
> Done !
> >
> >> > Frankly, I do not understand this logic :-) And your patch looks wrong -
> >> > it touches the "auto-format" code which you may consider more like a
> >> > "debugging" feature and should not rely on this in production.
> >> Sorry, but I don't understand what you mean by the "auto-format" code.
> >
> > Yeah, right, this comment was incorrect, sorry.
> >
> 
> I was thinking that instead of giving to ubiattach the MBB, we could
> give it the MBB percentage (maximum bad blocks percentage of the whole
> flash device).
> From this % and the whole flash size, we get the MBB number, and set
> beb_rsvd_level for each MTD part.

Well, I thought that it may be not flexible enough for some people,
because you cannot give 1.5%, since flaoting-point arithmetic in the
kernel is not used.

> It will be easier for userspace, as we won't have to set a different
> value for different flash size. The default 2% value will (almost)
> always be correct.
> We can even get rid of the CONFIG_MTD_UBI_BEB_RESERVE option.

Yes, this option would be killed.

> BTW, the real killer feature would be that the flash gives its NVB or
> MBB value in response to the READ_ID command, but unfortunately that's
> not the case...

Sure, you can also implement this. Add the corresponding field to
'struct mtd_info', 0 will mean "not known". UBI could pick it.

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


More information about the linux-mtd mailing list