Do I need to read the entire LittleFS partition with esptool to retrieve all files in it?

[t23319222]

The partition I use for my LittleFS is called spiffs:

Code: Select all

Name      , Type   , Subtype, Offset    , Size      , Flags     
nvs       , 0x1    , 0x2    , 0x9000    , 0x5000    ,
otadata   , 0x1    , 0x0    , 0xe000    , 0x2000    ,
app0      , 0x0    , 0x10   , 0x10000   , 0x140000  ,
app1      , 0x0    , 0x11   , 0x150000  , 0x140000  ,
spiffs    , 0x1    , 0x82   , 0x290000  , 0x160000  ,
coredump  , 0x1    , 0x3    , 0x3f0000  , 0x10000   ,

Currently I dump a littlefs.bin to my computer and extract its content to a folder on my computer to view the files and folders in LittleFS. To dump the spiffs partition, I currently use the command

Code: Select all

esptool.exe --port <serial_port> --baud <baud_rate> read-flash 0x290000 0x160000 <bin_file>

This is very slow because the partition is so large. I was wondering: Since I use less than 1% of the LittleFS storage space, can I somehow only read the relevant parts (where the actual file data is) of the partition? Or do I always need to read the entire partition?

[nopnop2002]

Is this not okay?

esptool.exe --port <serial_port> --baud <baud_rate> read-flash 0x290000 size_of_you_want <bin_file>

[t23319222]

The problem is that I don’t know the size of the data in advance. Most of the time, the partition isn’t even close to being full, but occasionally it’s nearly full.

Maybe I could read the partition header to determine how much space the files are using? But even if that’s possible, is there any guarantee of an upper address boundary—some point beyond which I can be certain no more files exist?

[MicroController]

But even if that’s possible, is there any guarantee of an upper address boundary—some point beyond which I can be certain no more files exist?

Not possible. Due to the nature of (most?) file systems, any part of any file's data may end up being stored in any location. This seems to be especially true for LittleFS because of its 'copy-on-write' strategy.