high revision count, config.block_cycles 25000 on AT25SF321B of endurance 100,000 program and erase cycles

[ChocolateCookie1000]

Hello,
I need clarification on the block_cycles parameter. Question 1) Is it supposed to be near the endurance of the flash chip? On the AT25SF321B-SHB-T, the data sheet says 100,00 program and erase cycles on page1.
https://www.renesas.com/en/document/dst/at25sf321b-datasheet?r=1608806

I put this for my config

#define FLASH_SIZE (4 * 1024 * 1024)
cfg.read_size = 256; 
cfg.prog_size = 256;  
cfg.cache_size = 256;  
cfg.block_size = 4096; 
cfg.block_count = FLASH_SIZE / cfg.block_size;
cfg.block_cycles = 25000;
cfg.lookahead_size = 16;  

I rewrite a file of 10 bytes every 6 minutes to the file system. I made a memory dump of the first few bytes and get
95 F8 0C 00 (little endian revision count) F0 0F FF F7 6C 69 74 74 6C 65 66 73(littlefs)
The revision count is 850,069. In the memory dump, most of the 4096 byte blocks of the flash are unused with FF. It is not distributing the wear on the chip.
Question 2) Is it correct to say that the dump says that the embedded system have really done 850,069 erases? I estimate it should have done file writes more in the order of 10,000.
Question 3) How do I choose a good value for cfg.block_cycles?

I remade the code on a PC with the PC's RAM and put cfg.block_cycles =500 and kept the cfg.prog_size = 256 . I put no delay of 10 minutes and tried for quantities of writes in the millions. I put in the callback of the erase an increment to an array to keep track of the quantity of erases per block number. On the PC, I get good spreading.

Question 5) If cfg.block_cycles is not the absolute max quantity of erase cycles on the block, how does littlefs know when to never erase a block of memory again?

[geky]

Hi @ChocolateCookie1000, thanks for creating an issue, sorry about the late response.

Question 1) Is it supposed to be near the endurance of the flash chip? On the AT25SF321B-SHB-T, the data sheet says 100,00 program and erase cycles on page1.

No! Unfortunately this has proven to be a confusing config option.

You should set block_cycles to somewhere in the range of 10-1000 (${\ll}$ 100,000). Higher numbers increase performance at the cost of wear distribution, though there are diminishing returns when block relocation stops being a bottleneck.

If you set block_cycles equal to the expected erase cycles you effectively disable wear-leveling.

The 500 number you used in your second example is reasonable.

This is being renamed to block_recycles to hopefully clear up some confusion, but backwards compatibility limits this to a major API change.

Question 2) Is it correct to say that the dump says that the embedded system have really done 850,069 erases? I estimate it should have done file writes more in the order of 10,000.

There's a small optimization we do here where we take whatever is on disk, align to the nearest block_cycles value, and increment from there. Guessing from your example, the revision count was probably incremented 69 times, which would mean 34ish erases (we alternate between two blocks when erasing in metadata pairs).

Using what's on-disk allows us to avoid erasing both blocks when allocating a metadata pair, saving 1 erase per relocation.

Revision counts are also compared using serial arithmetic, so overflow is not an issue.

Question 3) How do I choose a good value for cfg.block_cycles?

Unfortunately there's not been enough benchmarking to know optimal values across all hardware. It also likely depends on both the type of storage and how the filesystem is used, so what you're doing with measuring+testing it yourself is probably the best thing to do.

A good strategy is to probably start with a small number, such as 10, and increase it if you notice block relocations are a bottleneck. From some recent use, 10 seems like a reasonable default on NOR due to the implicit recycling created by logs supporting multiple commits, but I'm hesitant to make stronger claims.

Question 5) If cfg.block_cycles is not the absolute max quantity of erase cycles on the block, how does littlefs know when to never erase a block of memory again?

Ah, that's the neat part, it doesn't.

littlefs's wear-leveling strategy is preventative. By distributing wear across the device roughly evenly, if one block starts to fail, most likely all blocks are near the end of their life. This has the added benefit of not throwing away blocks due to transient errors (bus errors, gamma rays, etc), though the real reason is to simplify the filesystem.

There are plans to add optional bad block tracking in littlefs3 (#1111, unstable) through the addition of an on-disk block-map, but this work is still in progress.