search

PaulStoffregen / LittleFS

75 stars 20 forks source link

after LLformat check skip first LittleFS preFormat #6

Closed Defragster closed 3 years ago

Defragster commented 3 years ago

For test results see https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=260718&viewfull=1#post260718

QSPI: 108.1 secs :: lowLevelFormat 27.5 secs :: Big File write > 16728000 Bytes << CLEAN MEDIA - no pre-format 135.6 secs :: Big File write > 16728000 Bytes << DIRTY MEDIA

SPI: 348.4 secs :: lowLevelFormat 36.9 secs :: Big File write > 16728000 Bytes << CLEAN MEDIA - no pre-format 384.6 secs :: Big File write > 16728000 Bytes << DIRTY MEDIA

PaulStoffregen commented 3 years ago

Replied on the forum. https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=260732&viewfull=1#post260732

Duplicating here:

This code worries me.

The main problem is it assumes an entire flash block is blank and does not require erase if only the first 16 bytes are 0xFF. The huge problem is it never examines the other 4080 bytes (or more, when we support chips with larger sector size). If any of those bytes are not blank, this will cause data corruption!

Yes, I understand it only does this if checkFormat(true) was previously called. But just because a dangerous behavior is not the default does not make it any safer for users who do choose to use this (proposed) public API.

I probably will not merge this pull request.

Defragster commented 3 years ago

It was noted the current chips are mapped 1::1 >> 1Block to 1Erase. If future media alters this relationship a factor added to the 'info' structure for knwon supported chips could signify the mapping and when some number of Blocks exist in an erase area, as long as the math works to get the start of the erase area {which it would have to for erase to work and cover that block} - then each block in it could be read tested to be virgin format - or used already by the FS.

For that many block to 1Erase to work it would seem that LittleFS maintains a master list? It cannot format one subblock without knowing no others in the shared area are in active use.

Alternatively since PJRC code handles all the I/O it could perhaps maintain a clean/dirty bitmap list for reference. Made clean only with a LLformat - and marked dirty on each media write as needed to look up the need to perform the requested format? As long as the 1's saying clean are reliably set to 0 on made dirty - a single read of the right set of bits would indicate if the format were needed.

Defragster commented 3 years ago

Doing alternate approach ...