Re: [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling

[Richard Weinberger <richard@nod.at>]

Am 12.11.2014 um 14:32 schrieb Artem Bityutskiy:
> [Sort of off-topic]
> 
> On Wed, 2014-11-12 at 14:01 +0100, Richard Weinberger wrote:
>> Tanya stated that the read counters must not get lost.
> 
> I understood that this is more of "we try not to lose them, but if we
> lose, we can deal with this".
> 
>> But it can happen that you lose the fastmap. Fastmap is optional.
> 
> And new data structure would be kind of optional too.

Yeah, but it should be COMPAT_PRESERVE instead of COMPAT_DELETE.

>> I.e. if you boot an older kernel it will delete the fastmap. If you run
>> out of PEBs which can be used by fastmap, fastmap has to delete the current fastmap.
>> Same for too many write errors, etc...
> 
> It would be cool to document this in more details, say in the web site.
> If someone uses fastmap, they probably need to know exactly when it
> could "disappear", in order to try avoiding these conditions.

Will file a patch against mtd-www.git!

>> If we add the read-counters to fastmap we'd have to change the fastmap on-flash layout too.
> 
> But this is not the end of the world. Fastmap is still an experimental
> feature, and I personally consider it as "not yet proved to be ready for
> production", because I did not hear success stories yet. It does not
> mean there are no success stories. And this is just my perception, I may
> be wrong. So while not touching on-flash format is always a good goal,
> we may be less resistant about fastmap.

Yeah, if needed I will not block it.

>> (Unless we do very hacky tricks)
>> Also writing a fastmap is not cheap, we have to stop all IO. So, saving the read-counter will
>> be expensive and an performance problem.
> 
> For me this one sounds like a strong point. We do not really want to
> make fastmap change more often.

Exactly.

Thanks,
//richard