Re: [PATCH 2/2] ubiformat: Leave space for fastmap anchor

[Richard Weinberger <richard@nod.at>]

Am 22.10.2014 um 10:19 schrieb Tanya Brokhman:
> On 10/22/2014 11:15 AM, Richard Weinberger wrote:
>> Am 22.10.2014 um 09:48 schrieb Sascha Hauer:
>>> The fastmap code needs a free eraseblock in the first 64 erasblocks
>>> to write a fastmap anchor. Since ubiformat continuously writes the
>>> image to the flash the fastmap code won't find a free block and
>>> fastmap will be disabled.
>>
>> If UBI is unable to write a fastmap it will try again later.
>> So, it will be not disabled.
>>
>>> With this patch ubiformat skips flashing
>>> a block at the beginning thus allowing the fastmap code to write
>>> an anchor.
>>
>> Hmm, this is a bit hacky. What prevents UBI itself from using this free PEB
>> after the first attach? I.e. if a bitflip happens?
>> The in kernel code has already a mechanism to move used PEBs < 64 to make space
>> for the anchor.
>> IMHO the only sane approach is to create a fastmap enabled image directly with ubiformat.
>> While creating the initial fastmap code I had the plan to make mtd-tools fastmap aware
>> but simply run out of budget and so far nobody cared enough.
> 
> I care :) Its in my TODO to update ubinize to leave space for fastmap anchor (and perhaps generate a fastmap data as well but this is just a thought).

Good to know. :)
Please generate the fastmap data such that upon the very first attach fastmap can be used.
As I said leaving space for fastmap is hacky and still cannot guarantee that fastmap can find
a free PEB for its anchor.

Thanks,
//richard