From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling Date: Wed, 12 Nov 2014 15:32:29 +0200 Message-ID: <1415799149.22887.266.camel@sauron.fi.intel.com> References: <1414331342-27839-1-git-send-email-tlinder@codeaurora.org> <544D5BEC.50802@nod.at> <544E052B.1040505@codeaurora.org> <544E08AE.7080506@nod.at> <5450C997.9010205@codeaurora.org> <5450D6C4.4040400@nod.at> <54538ABC.1040605@codeaurora.org> <5453ABF9.4070208@nod.at> <5453AD4D.2000303@nod.at> <545630E1.8020505@codeaurora.org> <1415261234.958.171.camel@sauron.fi.intel.com> <545B66BA.4090904@codeaurora.org> <1415350722.958.286.camel@sauron.fi.intel.com> <54627350.9080509@codeaurora.org> <54628207.5030205@nod.at> <1415794063.22887.245.camel@sauron.fi.intel.com> <54635A42.2080102@nod.at> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com ([134.134.136.65]:4239 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752582AbaKLNcd (ORCPT ); Wed, 12 Nov 2014 08:32:33 -0500 In-Reply-To: <54635A42.2080102@nod.at> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Richard Weinberger Cc: Tanya Brokhman , linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org, jlauruhn@micron.com [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.