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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
