summaryrefslogtreecommitdiff
path: root/fs/jffs2
diff options
context:
space:
mode:
authorSascha Hauer <s.hauer@pengutronix.de>2019-11-05 09:12:51 +0100
committerRichard Weinberger <richard@nod.at>2019-11-17 22:45:57 +0100
commitf9c34bb529975fe9f85b870a80c53a83a3c5a182 (patch)
tree6a5cf84ad65ac0ed3499e10c68803d434b12a59d /fs/jffs2
parent6abf57262166b4f4294667fb5206ae7ba1ba96f5 (diff)
ubi: Fix producing anchor PEBs
When a new fastmap is about to be written UBI must make sure it has a free block for a fastmap anchor available. For this ubi_update_fastmap() calls ubi_ensure_anchor_pebs(). This stopped working with 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()"), with this commit the wear leveling code is blocked and can no longer produce free PEBs. UBI then more often than not falls back to write the new fastmap anchor to the same block it was already on which means the same erase block gets erased during each fastmap write and wears out quite fast. As the locking prevents us from producing the anchor PEB when we actually need it, this patch changes the strategy for creating the anchor PEB. We no longer create it on demand right before we want to write a fastmap, but instead we create an anchor PEB right after we have written a fastmap. This gives us enough time to produce a new anchor PEB before it is needed. To make sure we have an anchor PEB for the very first fastmap write we call ubi_ensure_anchor_pebs() during initialisation as well. Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
Diffstat (limited to 'fs/jffs2')
0 files changed, 0 insertions, 0 deletions