On 11/2/2014 3:54 PM, Richard Weinberger wrote:
Am 02.11.2014 um 14:23 schrieb Tanya Brokhman:
Okay, read-disturb will only happen if you read blocks *very* often. Do you
have numbers, datasheets, etc...?
Yes. In 0001-mtd-ubi-Read-disturb-infrastructure.patch you'll find:
#define UBI_RD_THRESHOLD 100000
Can't share more than that. This value is defined by card manufacturer and
configurable by this define.
Somehow I managed to oversee that value. It is as large as I expected.
But is is *very* sad that you can't share more details.
We'd have make this value configurable at runtime.
Other manufacturers may have other magical values...
Yea, thought of that as well while answering your email. will do. thanks!
Let's recap.
We need to address two issues:
a) If a PEB is ready very often we need to scrub it.
right. this is what the read-counter is for.
b) PEBs which are not read for a very long time need to be re-read/scrubbed to
detect bit-rot
it need to be scrubbed. this is for data retention and these pebs are found by
last_erase_timestamp. I referred to them as "pebs that are rarely accessed. "
Solving b) is easy, just re-read every PEB from time to time. No persistent
data at all is needed.
That isn't good enough. Because if we just re-read the peb we will find the
"problematic" once only when the read produces ecc errors. But if we relay on
that we may be too late
because we might hit ecc errors that we just wont be able to fix and data will
be lost. So the goal is *to prevent* ecc errors on read. That's why we need
both the read-counter
(for heavily read pebs) and the last_erase_timestamp (for once that are rarely
accessed).
To solve a) you suggest adding the read-counter to the UBI on-disk layout like
the erase-counter values.
No, not on disk layout. You're mixing the read-counter with the
last_erase_timestamp.
read-counter: maintained only at RAM, saved *only* as part of fastmap data. If
fastmap data is lost: read counters are lost too
last-erase-timestamp: part of ec_header, maintained on disk
You're right I mixed that up. Sorry.
Copy&Pasting from your other mail:
Another point:
What if we scrub every PEB once a week?
Why would that not work?
It will work but it's an overkill because we don't want to scrub (and erase)
pebs that don't need this because this way we will ware out the device in terms
on wear-leveling.
Besides, scrubbing all pebs will also be a performance hit.
A year has 52 weeks. So, in 10 (!) years we would scrub each PEB only 520 times.
Even if we scrub every day we'd only scrub each PEB 3650 times in 10 years.
I don't see any overhead at all. Of course only a stupid implementation would
scrub them at once, this would
be a performance issue.
Back to topic.
Storing the read-counters into fastmap also not a good idea because the fastmap
can get lost completely (by design).
yes,I'm aware of that. We have a default value for that case, and we're
trying to avoid fastmap being invalid...
Better store the read-counter lazily into a new internal UBI volume (use
UBI_COMPAT_PRESERVE).
not familiar with UBI_COMPAT_PRESERVE. will look into this and consider
your suggestion.
This way you can make sure that they are not lost.
I suggest the following:
a) Maintain the erase-counters in RAM
b) From time to time write them to an internal UBI volume. (e.g. at detach time
and once a day).
c) Implement a logic in UBI which scrubs a PEB if it got a lot of reads.
You could do c) even in userspace.
And for bit-rot detection you can do the same, but with timestamps instead of
read-counters...
Artem, what do you think?
Thanks,
//richard
Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
