ubi2 error: ubi_refill_pools: no free eraseblocks

ubi2 error: ubi_refill_pools: no free eraseblocks

[Rickard X Andersson]

Hi,

During a stress test we get the following error:

"ubi2 error: ubi_refill_pools: no free eraseblocks"

Is this something we need to take some action to solve or is it unharmful?

We write 50000 database entries via sqlcipher and the error is printed when we are almost finished. Everything seems to work alright and all entries seems to be in place.
Each entry is about 1,5kB size. After all entries has been written the partition is 41 % full:

ubi2:mydata_volume        457368    183528    269004  41% /var/lib/mypath

The following NAND memory is used:

nand: Toshiba TH58NVG2S3HBAI4 4G 3.3V 8-bit
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128

Best regards,
Rickard Andersson

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: ubi2 error: ubi_refill_pools: no free eraseblocks

[Richard Weinberger]

On Wed, May 27, 2020 at 3:21 PM Rickard X Andersson
<Rickard.Andersson@axis.com> wrote:
> During a stress test we get the following error:
>
> "ubi2 error: ubi_refill_pools: no free eraseblocks"
>
> Is this something we need to take some action to solve or is it unharmful?

It basically means that you're draining free blocks faster than it can
produce (by erasing outdated ones, etc..).
So nothing harmful but I'd worry if you face this during normal
operation (non-stresstest).
Mostly because when this situation happens UBI has to do many things
synchronously and things will get
slow.

-- 
Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: ubi2 error: scan_pool: unable to read EC header! PEB:569 err:1

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Rickard X Andersson" <Rickard.Andersson@axis.com>
> An: "linux-mtd" <linux-mtd@lists.infradead.org>, "Artem Bityutskiy" <dedekind1@gmail.com>, "richard" <richard@nod.at>,
> "Richard Weinberger" <richard.weinberger@gmail.com>
> Gesendet: Mittwoch, 12. Januar 2022 11:54:01
> Betreff: ubi2 error: scan_pool: unable to read EC header! PEB:569 err:1

> Hi,
> 
> After a firmware upgrade the following error is reported by testers after
> reboot:
> 
> [    8.017720][  T306] ubi2 error: scan_pool: unable to read EC header! PEB:569
> err:1
> [    8.017900][  T306] ubi2 error: ubi_scan_fastmap: Attach by fastmap failed,
> doing a full scan!

1 is UBI_IO_FF. So a fastmap pool points to a freshly erased block.
 
> Is this something we need to take some action to solve or is it unharmful?
> Everything seems to work as normal.

Looks like erasing a PEB was interrupted (by a power-cut) before UBI had a chance to
write an EC header to it and Fastmap being paranoid refused to do a fast attach.

After that event, did everything work again and Fastmap is happy?

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: SV: ubi2 error: scan_pool: unable to read EC header! PEB:569 err:1

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Rickard X Andersson" <Rickard.Andersson@axis.com>
> An: "richard" <richard@nod.at>
> CC: "linux-mtd" <linux-mtd@lists.infradead.org>, "Artem Bityutskiy" <dedekind1@gmail.com>
> Gesendet: Mittwoch, 12. Januar 2022 17:25:57
> Betreff: SV: ubi2 error: scan_pool: unable to read EC header! PEB:569 err:1

> Thanks for the quick answer!
> 
> Too me it looks like fastmap is happy and everything is working well, see log
> below.
> 
> <3>[    8.017720][  T306] ubi2 error: scan_pool: unable to read EC header!
> PEB:569 err:1
> <3>[    8.017900][  T306] ubi2 error: ubi_scan_fastmap: Attach by fastmap
> failed, doing a full scan!
> <5>[   10.456601][  T306] ubi2: scanning is finished
> <5>[   10.477819][  T306] ubi2: attached mtd5 (name "data", size 512 MiB)
> <5>[   10.477980][  T306] ubi2: PEB size: 131072 bytes (128 KiB), LEB size:
> 126976 bytes
> <5>[   10.478064][  T306] ubi2: min./max. I/O unit sizes: 2048/2048, sub-page
> size 2048
> <5>[   10.478147][  T306] ubi2: VID header offset: 2048 (aligned 2048), data
> offset: 4096
> <5>[   10.478292][  T306] ubi2: good PEBs: 4092, bad PEBs: 4, corrupted PEBs: 0
> <5>[   10.478376][  T306] ubi2: user volume: 1, internal volumes: 1, max.
> volumes count: 128
> <5>[   10.478524][  T306] ubi2: max/mean erase counter: 9666/740, WL threshold:
> 4096, image sequence number: 581957443
> <5>[   10.478668][  T306] ubi2: available PEBs: 0, total reserved PEBs: 4092,
> PEBs reserved for bad PEB handling: 76
> <5>[   10.478825][  T337] ubi2: background thread "ubi_bgt2d" started, PID 337
> <5>[   10.482212][   T16] ubi2: Starting ubi_update_fastmap
> <5>[   10.522300][   T16] ubi2: Finished ubi_update_fastmap
> 
> I do not think the interruption was by a power-cut, but I am not sure. Do you
> think the interruption could be caused by a linux reboot using the
> reboot/restart command?

If you interrupt UBI by software, you can face the same situation too.
I guess you don't run ubidetach upon reboot?

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/