From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Shmulik Ladkani <shmulik.ladkani@gmail.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Richard Weinberger <richard@nod.at>,
Richard Genoud <richard.genoud@gmail.com>
Subject: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Date: Wed, 4 Jul 2012 11:05:59 +0300 [thread overview]
Message-ID: <1341389164-24409-1-git-send-email-shmulik.ladkani@gmail.com> (raw)
The existing mechanism of reserving PEBs for bad PEB handling has two
flaws:
- It is calculated as a percentage of good PEBs instead of total PEBs.
- There's no limit on the amount of PEBs UBI reserves for future bad
eraseblock handling.
This patchset changes the mechanism to overcome these flaws.
The caculation of PEBs reserved for bad PEB handling will be based on a
new property, ubi->bad_peb_limit, which specifies an upper limit of PEBs
ubi expects to go bad (currently initialized to a fixed percentage of
total PEBs in the ubi device, configurable via CONFIG_MTD_UBI_BEB_LIMIT,
but can be easily augmented to support a per ubi-attach limit).
The desired level of PEBs reserved for bad PEB handling (beb_rsvd_level)
is set to the maximum expected bad eraseblocks (bad_peb_limit) minus the
existing number of bad eraseblocks (bad_peb_count).
The actual amount of PEBs reserved for bad PEB handling is usually set
to the desired level (but in some circumstances may be lower than the
desired level, e.g. when attaching to a device that has too few
available PEBs to satisfy the desired level).
In the case where the device has too many bad PEBs (above the expected
limit), then the desired level, and the actual amount of PEBs reserved
are set to zero. No PEBs will be set aside for future bad eraseblock
handling - even if some PEBs are made available (e.g. by shrinking a
volume).
If another PEB goes bad, and there are available PEBs, then the
eraseblock will be marked bad (consuming one available PEB). But if
there are no available PEBs, ubi will go into readonly mode.
Shmulik Ladkani (5):
ubi: introduce ubi->bad_peb_limit
ubi: Limit amount of reserved eraseblocks for bad PEB handling
ubi: kill CONFIG_MTD_UBI_BEB_RESERVE
ubi: trivial: fix comment of ubi_calculate_reserved()
ubi: harmonize the update of ubi->beb_rsvd_pebs
arch/arm/configs/sam9_l9260_defconfig | 2 +-
drivers/mtd/ubi/Kconfig | 24 ++++++++++-------
drivers/mtd/ubi/build.c | 13 +++++++++-
drivers/mtd/ubi/misc.c | 44 +++++++++++++++++++++++++++++---
drivers/mtd/ubi/ubi.h | 6 ++--
drivers/mtd/ubi/vmt.c | 20 +-------------
drivers/mtd/ubi/wl.c | 44 +++++++++++++++++++++------------
7 files changed, 99 insertions(+), 54 deletions(-)
--
1.7.9
next reply other threads:[~2012-07-04 8:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 8:05 Shmulik Ladkani [this message]
2012-07-04 8:06 ` [PATCH 1/5] ubi: introduce ubi->bad_peb_limit Shmulik Ladkani
2012-07-18 7:09 ` Artem Bityutskiy
2012-07-18 10:40 ` Artem Bityutskiy
2012-07-19 6:16 ` Shmulik Ladkani
2012-07-30 13:00 ` Artem Bityutskiy
2012-07-04 8:06 ` [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling Shmulik Ladkani
2012-07-09 10:15 ` Richard Genoud
2012-07-09 11:02 ` Shmulik Ladkani
2012-07-18 10:28 ` Artem Bityutskiy
2012-07-18 11:01 ` Artem Bityutskiy
2012-07-18 19:55 ` Shmulik Ladkani
2012-07-19 3:35 ` Artem Bityutskiy
2012-07-18 11:40 ` Artem Bityutskiy
2012-07-04 8:06 ` [PATCH 3/5] ubi: kill CONFIG_MTD_UBI_BEB_RESERVE Shmulik Ladkani
2012-07-04 8:06 ` [PATCH 4/5] ubi: trivial: fix comment of ubi_calculate_reserved() Shmulik Ladkani
2012-07-18 10:38 ` Artem Bityutskiy
2012-07-04 8:06 ` [PATCH 5/5] ubi: harmonize the update of ubi->beb_rsvd_pebs Shmulik Ladkani
2012-07-18 11:32 ` Artem Bityutskiy
2012-07-04 8:35 ` [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation Richard Weinberger
2012-07-04 11:33 ` Shmulik Ladkani
2012-07-06 15:27 ` Richard Genoud
2012-07-07 6:14 ` Shmulik Ladkani
2012-07-07 8:32 ` Richard Genoud
2012-07-09 6:58 ` Richard Genoud
2012-07-16 15:33 ` Artem Bityutskiy
2012-07-17 7:23 ` Shmulik Ladkani
2012-07-18 6:54 ` Artem Bityutskiy
2012-07-30 13:56 ` Artem Bityutskiy
2012-07-31 8:19 ` Shmulik Ladkani
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=1341389164-24409-1-git-send-email-shmulik.ladkani@gmail.com \
--to=shmulik.ladkani@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.genoud@gmail.com \
--cc=richard@nod.at \
/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).