From: Richard Weinberger <richard@nod.at>
To: Johannes Bauer <weolanwaybqm@spornkuller.de>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Wear-leveling peculiarities
Date: Mon, 18 May 2015 22:47:55 +0200 [thread overview]
Message-ID: <555A4FFB.5040006@nod.at> (raw)
In-Reply-To: <555A4D38.3070702@spornkuller.de>
Am 18.05.2015 um 22:36 schrieb Johannes Bauer:
> On 18.05.2015 19:58, Richard Weinberger wrote:
>
>> Wear-leveling is done on UBI and UBIFS.
>> What is CONFIG_MTD_UBI_WL_THRESHOLD set to?
>
> Ooops. I honestly don't know, will check this out tomorrow. I must admit
> that I wasn't aware of this setting at all.
>
>> >From the Kconfig help:
>> This parameter defines the maximum difference between the highest
>> erase counter value and the lowest erase counter value of eraseblocks
>> of UBI devices. When this threshold is exceeded, UBI starts performing
>> wear leveling by means of moving data from eraseblock with low erase
>> counter to eraseblocks with high erase counter.
>>
>> The default value should be OK for SLC NAND flashes, NOR flashes and
>> other flashes which have eraseblock life-cycle 100000 or more.
>> However, in case of MLC NAND flashes which typically have eraseblock
>> life-cycle less than 10000, the threshold should be lessened (e.g.,
>> to 128 or 256, although it does not have to be power of 2)
>>
>> I suspect that your threshold was never reached.
>
> Yes, I suspect you're right here.
If you did not set CONFIG_MTD_UBI_WL_THRESHOLD it is 4096.
So, regular wear-leveling did never happen.
>> >From your provided graph it looks like all erase block have been
>> erased t most 300 times.
>> If your NAND starts dying after 300 erases you're in trouble.
>
> And I fear you're right here as well :-(
>
> Although there's no definitive saying how many page writes the failed
> units had because the defective sectors are so broken that the kernel
> barfs out I/O errors. That means I can't even read the OOB metadata.
The OOB-Data does not matter. UBI is not using OOB.
So, you have to figure out why UBIFS is dying. Maybe it is a NAND issue.
Thanks,
//richard
next prev parent reply other threads:[~2015-05-18 20:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 13:53 Wear-leveling peculiarities Johannes Bauer
2015-05-18 14:09 ` Johannes Bauer
2015-05-18 17:58 ` Richard Weinberger
2015-05-18 17:59 ` Richard Weinberger
2015-05-18 20:38 ` Johannes Bauer
[not found] ` <555A4D38.3070702@spornkuller.de>
2015-05-18 20:47 ` Richard Weinberger [this message]
2015-05-26 9:38 ` Johannes Bauer
2015-05-26 10:08 ` Richard Weinberger
2015-05-26 11:14 ` Johannes Bauer
2015-05-26 16:19 ` Jeff Lauruhn (jlauruhn)
2015-05-26 16:24 ` Johannes Bauer
2015-05-26 16:29 ` Richard Weinberger
2015-05-26 18:20 ` Ezequiel Garcia
2015-05-19 9:17 ` valent.turkovic
2015-05-26 9:43 ` Johannes Bauer
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=555A4FFB.5040006@nod.at \
--to=richard@nod.at \
--cc=linux-mtd@lists.infradead.org \
--cc=weolanwaybqm@spornkuller.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.