• Zhihao Cheng's avatar
    ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs · 90e0be56
    Zhihao Cheng authored
    The anchor PEB must be picked from first 64 PEBs, these PEBs could have
    large erase counter greater than other PEBs especially when free space
    is nearly running out.
    The ubi_update_fastmap will be called as long as pool/wl_pool is empty,
    old anchor PEB is erased when updating fastmap. Given an UBI device with
    N PEBs, free PEBs is nearly running out and pool will be filled with 1
    PEB every time ubi_update_fastmap invoked. So t=N/POOL_SIZE[1]/64 means
    that in worst case the erase counter of first 64 PEBs is t times greater
    than other PEBs in theory.
    After running fsstress for 24h, the erase counter statistics for two UBI
    devices shown as follow(CONFIG_MTD_UBI_WL_THRESHOLD=128):
    
    Device A(1024 PEBs, pool=50, wl_pool=25):
    =========================================================
    from              to     count      min      avg      max
    ---------------------------------------------------------
    0        ..        9:        0        0        0        0
    10       ..       99:        0        0        0        0
    100      ..      999:        0        0        0        0
    1000     ..     9999:        0        0        0        0
    10000    ..    99999:      960    29224    29282    29362
    100000   ..      inf:       64   117897   117934   117940
    ---------------------------------------------------------
    Total               :     1024    29224    34822   117940
    
    Device B(8192 PEBs, pool=256, wl_pool=128):
    =========================================================
    from              to     count      min      avg      max
    ---------------------------------------------------------
    0        ..        9:        0        0        0        0
    10       ..       99:        0        0        0        0
    100      ..      999:        0        0        0        0
    1000     ..     9999:     8128     2253     2321     2387
    10000    ..    99999:       64    35387    35387    35388
    100000   ..      inf:        0        0        0        0
    ---------------------------------------------------------
    Total               :     8192     2253     2579    35388
    
    The key point is reducing fastmap updating frequency by enlarging
    POOL_SIZE, so let UBI reserve ubi->fm_pool.max_size PEBs during
    attaching. Then POOL_SIZE will become ubi->fm_pool.max_size/2 even
    in free space running out case.
    Given an UBI device with 8192 PEBs(16384\8192\4096 is common
    large-capacity flash), t=8192/128/64=1. The fastmap updating will
    happen in either wl_pool or pool is empty, so setting fm_pool_rsv_cnt
    as ubi->fm_pool.max_size can fill wl_pool in full state.
    
    After pool reservation, running fsstress for 24h:
    
    Device A(1024 PEBs, pool=50, wl_pool=25):
    =========================================================
    from              to     count      min      avg      max
    ---------------------------------------------------------
    0        ..        9:        0        0        0        0
    10       ..       99:        0        0        0        0
    100      ..      999:        0        0        0        0
    1000     ..     9999:        0        0        0        0
    10000    ..    99999:     1024    33801    33997    34056
    100000   ..      inf:        0        0        0        0
    ---------------------------------------------------------
    Total               :     1024    33801    33997    34056
    
    Device B(8192 PEBs, pool=256, wl_pool=128):
    =========================================================
    from              to     count      min      avg      max
    ---------------------------------------------------------
    0        ..        9:        0        0        0        0
    10       ..       99:        0        0        0        0
    100      ..      999:        0        0        0        0
    1000     ..     9999:     8192     2205     2397     2460
    10000    ..    99999:        0        0        0        0
    100000   ..      inf:        0        0        0        0
    ---------------------------------------------------------
    Total               :     8192     2205     2397     2460
    
    The difference of erase counter between first 64 PEBs and others is
    under WL_FREE_MAX_DIFF(2*UBI_WL_THRESHOLD=2*128=256).
      Device A: 34056 - 33801 = 255
      Device B: 2460 - 2205 = 255
    
    Next patch will add a switch to control whether UBI needs to reserve
    PEBs for filling pool.
    
    Fixes: dbb7d2a8 ("UBI: Add fastmap core")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787Signed-off-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
    90e0be56
wl.h 1.37 KB