diff options
author | Arne Edholm <arne.edholm@axis.com> | 2020-01-13 15:56:22 +0100 |
---|---|---|
committer | Richard Weinberger <richard@nod.at> | 2020-06-02 22:53:05 +0200 |
commit | 4b68bf9a69d22dd512d61d5f0ba01b065b01ede6 (patch) | |
tree | 9396f6f7e636d2296d21f3bdbdbcd6b77119e62c /drivers/mtd/ubi/wl.c | |
parent | 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 (diff) | |
download | linux-stable-4b68bf9a69d22dd512d61d5f0ba01b065b01ede6.tar.gz linux-stable-4b68bf9a69d22dd512d61d5f0ba01b065b01ede6.tar.bz2 linux-stable-4b68bf9a69d22dd512d61d5f0ba01b065b01ede6.zip |
ubi: Select fastmap anchor PEBs considering wear level rules
There is a risk that the fastmap anchor PEB is alternating between
just two PEBs, the current anchor and the previous anchor that was just
deleted. As the fastmap pools gets the first take on free PEBs, the
pools may leave no free PEBs to be selected as the new anchor,
resulting in the two PEBs alternating behaviour. If the anchor PEBs gets
a high erase count the PEBs will not be used by the pools but remain in
ubi->free, even more increasing the likelihood they will be used as
anchors.
Getting stuck using only a couple of PEBs continuously will result in an
uneven wear, eventually leading to failure.
To fix this:
- Choose the fastmap anchor when the most free PEBs are available. This is
during rebuilding of the fastmap pools, after the unused pool PEBs are
added to ubi->free but before the pools are populated again from the
free PEBs. Also reserve an additional second best PEB as a candidate
for the next time the fast map anchor is updated. If a better PEB is
found the next time the fast map anchor is updated, the candidate is
made available for building the pools.
- Enable anchor move within the anchor area again as it is useful for
distributing wear.
- The anchor candidate for the next fastmap update is the most suited free
PEB. Check this PEB's erase count during wear leveling. If the wear
leveling limit is exceeded, the PEB is considered unsuitable for now. As
all other non used anchor area PEBs should be even worse, free up the
used anchor area PEB with the lowest erase count.
Signed-off-by: Arne Edholm <arne.edholm@axis.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Diffstat (limited to 'drivers/mtd/ubi/wl.c')
-rw-r--r-- | drivers/mtd/ubi/wl.c | 28 |
1 files changed, 19 insertions, 9 deletions
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c index 5146cce5fe32..27636063ed1b 100644 --- a/drivers/mtd/ubi/wl.c +++ b/drivers/mtd/ubi/wl.c @@ -687,20 +687,27 @@ static int wear_leveling_worker(struct ubi_device *ubi, struct ubi_work *wrk, } #ifdef CONFIG_MTD_UBI_FASTMAP + e1 = find_anchor_wl_entry(&ubi->used); + if (e1 && ubi->fm_next_anchor && + (ubi->fm_next_anchor->ec - e1->ec >= UBI_WL_THRESHOLD)) { + ubi->fm_do_produce_anchor = 1; + /* fm_next_anchor is no longer considered a good anchor + * candidate. + * NULL assignment also prevents multiple wear level checks + * of this PEB. + */ + wl_tree_add(ubi->fm_next_anchor, &ubi->free); + ubi->fm_next_anchor = NULL; + ubi->free_count++; + } + if (ubi->fm_do_produce_anchor) { - e1 = find_anchor_wl_entry(&ubi->used); if (!e1) goto out_cancel; e2 = get_peb_for_wl(ubi); if (!e2) goto out_cancel; - /* - * Anchor move within the anchor area is useless. - */ - if (e2->pnum < UBI_FM_MAX_START) - goto out_cancel; - self_check_in_wl_tree(ubi, e1, &ubi->used); rb_erase(&e1->u.rb, &ubi->used); dbg_wl("anchor-move PEB %d to PEB %d", e1->pnum, e2->pnum); @@ -1079,8 +1086,11 @@ static int __erase_worker(struct ubi_device *ubi, struct ubi_work *wl_wrk) if (!err) { spin_lock(&ubi->wl_lock); - if (!ubi->fm_anchor && e->pnum < UBI_FM_MAX_START) { - ubi->fm_anchor = e; + if (!ubi->fm_next_anchor && e->pnum < UBI_FM_MAX_START) { + /* Abort anchor production, if needed it will be + * enabled again in the wear leveling started below. + */ + ubi->fm_next_anchor = e; ubi->fm_do_produce_anchor = 0; } else { wl_tree_add(e, &ubi->free); |