linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: dedekind1@gmail.com
Cc: linux-arm-msm@vger.kernel.org, jlauruhn@micron.com,
	linux-mtd@lists.infradead.org,
	Tanya Brokhman <tlinder@codeaurora.org>
Subject: Re: [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling
Date: Wed, 12 Nov 2014 14:01:54 +0100	[thread overview]
Message-ID: <54635A42.2080102@nod.at> (raw)
In-Reply-To: <1415794063.22887.245.camel@sauron.fi.intel.com>



Am 12.11.2014 um 13:07 schrieb Artem Bityutskiy:
> On Tue, 2014-11-11 at 22:39 +0100, Richard Weinberger wrote:
>> Please don't (ab)use fastmap. If you really need persistent read-counters use an internal UBI volume.
> 
> Just like you, I do not think the proposed solution is the right answer
> to the problem, at least so far. But if we imagine that Tanya proves
> that the counters is the right thing, storing them in fastmap would be
> the first thing which comes to mind. Just calling this an abuse without
> explaining (even if this is right) is not very collaborative.

I explaind that already.
There have been so many mails on this topic that some facts may got lost.

Tanya stated that the read counters must not get lost.
But it can happen that you lose the fastmap. Fastmap is optional.
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...

If we add the read-counters to fastmap we'd have to change the fastmap on-flash layout too.
(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.

Thanks,
//richard

  reply	other threads:[~2014-11-12 13:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-26 13:49 [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling Tanya Brokhman
2014-10-26 20:39 ` Richard Weinberger
2014-10-27  8:41   ` Tanya Brokhman
2014-10-27  8:56     ` Richard Weinberger
2014-10-29 11:03       ` Tanya Brokhman
2014-10-29 12:00         ` Richard Weinberger
2014-10-31 13:12           ` Tanya Brokhman
2014-10-31 15:34             ` Richard Weinberger
2014-10-31 15:39               ` Richard Weinberger
2014-10-31 22:55                 ` Jeff Lauruhn (jlauruhn)
2014-11-02 13:30                   ` Tanya Brokhman
2014-11-07  9:21                     ` Artem Bityutskiy
2014-11-02 13:25                 ` Tanya Brokhman
2014-11-06  8:07                   ` Artem Bityutskiy
2014-11-06 12:16                     ` Tanya Brokhman
2014-11-07  8:55                       ` Artem Bityutskiy
2014-11-07  8:58                       ` Artem Bityutskiy
2014-11-11 20:36                         ` Tanya Brokhman
2014-11-11 21:39                           ` Richard Weinberger
2014-11-12 12:07                             ` Artem Bityutskiy
2014-11-12 13:01                               ` Richard Weinberger [this message]
2014-11-12 13:32                                 ` Artem Bityutskiy
2014-11-12 15:37                                   ` Richard Weinberger
2014-11-12 11:55                           ` Artem Bityutskiy
2014-11-13 12:13                             ` Tanya Brokhman
2014-11-13 13:36                               ` Artem Bityutskiy
2014-11-23  8:13                                 ` Tanya Brokhman
2014-11-02 13:23               ` Tanya Brokhman
2014-11-02 13:54                 ` Richard Weinberger
2014-11-02 14:12                   ` Tanya Brokhman
2014-11-02 17:02                     ` Richard Weinberger
2014-11-02 17:18                       ` Tanya Brokhman
     [not found] <201411101307.03225.jbe@pengutronix.de>
2014-11-10 12:35 ` Richard Weinberger
2014-11-10 13:12   ` Juergen Borleis
2014-11-11  9:23     ` Richard Weinberger
2014-11-10 13:13   ` Ricard Wanderlof
2014-11-10 13:42     ` Juergen Borleis
2014-11-10 13:52       ` Ricard Wanderlof

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54635A42.2080102@nod.at \
    --to=richard@nod.at \
    --cc=dedekind1@gmail.com \
    --cc=jlauruhn@micron.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tlinder@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).