From: Artem Bityutskiy <dedekind1@gmail.com>
To: Richard Genoud <richard.genoud@gmail.com>
Cc: linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBI: add minimal amount of reserved erase blocks in Kconfig
Date: Thu, 28 Jun 2012 17:39:11 +0300 [thread overview]
Message-ID: <1340894351.3070.121.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <1340636918-7505-1-git-send-email-richard.genoud@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]
Hi, first of all, this 1% is does is not good enough for modern devices.
It is just a default I picked out of the thin air.
What we really need is to make it possible to specify beb_rsvd_level at
attach time. I believe it is not difficult to implement:
1. Add a parameter to ubiattach
2. Extend the attach ioctl and add beb_rsvd_level there. We have 12
unused bytes in 'struct ubi_attach_req'.
3. Extend the "mtd" module parameter and allow to specify beb_rsvd_level
there as well.
That's it - you can specify the needed numbers for your flash.
to make this per-MTD device
On Mon, 2012-06-25 at 17:08 +0200, Richard Genoud wrote:
> The problem with this behaviour is that NAND flash manufacturers give a
> minimum number of valid block (NVB) during the endurance life of the
> device.
> E.G.:
> Parameter Symbol Min Max Unit Notes
> --------------------------------------------------------------
> Valid block number NVB 1004 1024 Blocks 1
> Note:
> 1. Invalid blocks are block that contain one or more bad bits beyond
> ECC. The device may contain bad blocks upon shipment. Additional bad
> blocks may develop over time; however, the total number of available
> blocks will not drop below NVB during the endurance life of the device.
OK, in this discussion is is easier to talk about maximum bad blocks
(MBB) rather than minimum good blocks, though. So basically, the vendor
guarantees that there will be at most MBB bad blocks.
> From this number we can deduce the maximum number of bad PEB that a
> device will contain during its endurance life :
> A 128MiB NAND flash (1024 PEB) will not have less than 20 bad blocks
> during the flash endurance life.
OK.
> BUT, the manufacturer doesn't tell where those bad block will appear. He
> doesn't say either if they will be equally disposed on the whole device
> (and I'm pretty sure they won't).
Right, then if you implement what I suggested, you'll pass
"beb_rsvd_level=20" when attaching both partitions.
> So, according to the datasheets, we should reserve the maximum number of
> bad PEB for each UBI volume.
> (Worst case scenario: 20 bad blocks appears on the smallest UBI volume.)
Err, not smallest UBI volume, but smallest MTD partition. We reserve
PEBs per-MTD device.
> => The actual parameter MTD_UBI_BEB_RESERVE is not enough to cover this
> scenario. We need to set a minimal number of reserved PEB for a UBI
> volume.
Frankly, I do not understand this logic :-) And your patch looks wrong -
it touches the "auto-format" code which you may consider more like a
"debugging" feature and should not rely on this in production.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-28 14:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 15:08 [PATCH] UBI: add minimal amount of reserved erase blocks in Kconfig Richard Genoud
2012-06-28 14:39 ` Artem Bityutskiy [this message]
2012-06-28 16:07 ` Richard Genoud
2012-06-28 16:22 ` Artem Bityutskiy
2012-06-29 7:17 ` Richard Genoud
2012-06-29 14:10 ` Artem Bityutskiy
2012-06-29 14:57 ` Richard Genoud
2012-06-29 15:07 ` Artem Bityutskiy
2012-06-28 17:53 ` Shmulik Ladkani
2012-06-29 12:47 ` Artem Bityutskiy
2012-06-30 20:43 ` Shmulik Ladkani
2012-07-02 6:15 ` Richard Genoud
2012-07-03 10:46 ` Artem Bityutskiy
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=1340894351.3070.121.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.genoud@gmail.com \
/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