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/ubi.h | |
| parent | 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 (diff) | |
| download | linux-4b68bf9a69d22dd512d61d5f0ba01b065b01ede6.tar.gz linux-4b68bf9a69d22dd512d61d5f0ba01b065b01ede6.tar.bz2 linux-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/ubi.h')
| -rw-r--r-- | drivers/mtd/ubi/ubi.h | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h index 73c67e5c08f8..2fd84f5efaad 100644 --- a/drivers/mtd/ubi/ubi.h +++ b/drivers/mtd/ubi/ubi.h @@ -491,7 +491,8 @@ struct ubi_debug_info { * @fm_work: fastmap work queue * @fm_work_scheduled: non-zero if fastmap work was scheduled * @fast_attach: non-zero if UBI was attached by fastmap - * @fm_anchor: The next anchor PEB to use for fastmap + * @fm_anchor: The new anchor PEB used during fastmap update + * @fm_next_anchor: An anchor PEB candidate for the next time fastmap is updated * @fm_do_produce_anchor: If true produce an anchor PEB in wl * * @used: RB-tree of used physical eraseblocks @@ -602,6 +603,7 @@ struct ubi_device { int fm_work_scheduled; int fast_attach; struct ubi_wl_entry *fm_anchor; + struct ubi_wl_entry *fm_next_anchor; int fm_do_produce_anchor; /* Wear-leveling sub-system's stuff */ |