[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. > 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. > 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. > (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. Thanks, Artem. -- 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
