[PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2
Zhihao Cheng
chengzhihao1 at huawei.com
Mon Jan 10 18:48:24 PST 2022
Hi Richard,
> scan_ai->fastmap may contain also old fastmap PEBs.
> In the area < UBI_FM_MAX_START you can find outdated fastmap PEBs.
> e.g. after power-cut.
> That's why scan_ai->fastmap is copied into ai->fastmap.
> Later in ubi_wl_init() these outdated PEBs will get erased.
> So, you cannot remove this code.
I thought old fastmap PEBs(async erase works in ubi_update_fastmap())
will be counted into erase PEBs in the next attaching process, because I
saw following code snippet in ubi_write_fastmap():
1260 list_for_each_entry(ubi_wrk, &ubi->works, list) {
1261 if (ubi_is_erase_work(ubi_wrk)) {
1262 wl_e = ubi_wrk->e;
1263 ubi_assert(wl_e);
1264
1265 fec = (struct ubi_fm_ec *)(fm_raw +
fm_pos);
1266
1267 fec->pnum = cpu_to_be32(wl_e->pnum);
1268 set_seen(ubi, wl_e->pnum, seen_pebs);
1269 fec->ec = cpu_to_be32(wl_e->ec);
1270
1271 erase_peb_count++;
1272 fm_pos += sizeof(*fec);
1273 ubi_assert(fm_pos <= ubi->fm_size);
1274 }
1275 }
1276 fmh->erase_peb_count = cpu_to_be32(erase_peb_count);
Half-writing on fastmap will be recognized in scanning, and UBI
fallbacks full scanning, So, I come up with two situations:
1. power-cut before new fastmap written, the old fastmap is completely
saved until next attaching, and some free PEBs are written with new
fastmap data. Luckly, fastmap anchor PEB's vid header is written first
of all, bad fastmap will be returned by ubi_attach_fastmap() in next
attaching.
2. power-cut after new fastmap written, the old fastmap PEBs will be
added into 'ai->erase' list in next attaching.
Did I miss other possible circumstances?
>
> But I fully agree with you that the fm->used_blocks > 1 case is not correct.
> I fear if scan_ai->fastmap contains old fastmap PEBs and fm->used_blocks is > 1
> we need to fall back to scanning mode while attaching.
More information about the linux-mtd
mailing list