[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a7a5cce-1ee1-70b6-d368-615dfa0a617a@huawei.com>
Date: Tue, 11 Jan 2022 21:23:52 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Richard Weinberger <richard@....at>
CC: Miquel Raynal <miquel.raynal@...tlin.com>,
Vignesh Raghavendra <vigneshr@...com>,
mcoquelin stm32 <mcoquelin.stm32@...il.com>,
"kirill shutemov" <kirill.shutemov@...ux.intel.com>,
Sascha Hauer <s.hauer@...gutronix.de>,
linux-mtd <linux-mtd@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into
'ai->fastmap' when fm->used_blocks>=2
在 2022/1/11 19:57, Richard Weinberger 写道:
> ubi_wl_init() is called in both cases, with and without fastmap.
I agree.
> And ai->fastmap contains all anchor PEBs that scan_fast() found.
> This can be the most recent but also outdated anchor PEBs.
Is it exists a case that outdated fastmap PEBs are neither counted into
'fmhdr->erase_peb_count' nor scanned into 'ai->fastmap' after attaching
by fastmap.
1853 if (ubi->lookuptbl[aeb->pnum])
1854 continue;
1855
1856 /*
1857 * The fastmap update code might not find a
free PEB for
1858 * writing the fastmap anchor to and then
reuses the
1859 * current fastmap anchor PEB. When this
PEB gets erased
1860 * and a power cut happens before it is
written again we
1861 * must make sure that the fastmap attach
code doesn't
1862 * find any outdated fastmap anchors, hence
we erase the
1863 * outdated fastmap anchor PEBs
synchronously here.
1864 */
1865 if (aeb->vol_id == UBI_FM_SB_VOLUME_ID)
1866 sync = true;
I think UBI attaches failed by fastmap if kernel goes here.
1870 err = erase_aeb(ubi, aeb, sync);
Powered by blists - more mailing lists