joltwallet/esp_littlefs

Feature Request: Update to LittleFS core v2.8

Jason2866 opened this issue ยท 7 comments

@BrianPugh Thx for your great work providing this repo!

Should be able to get around to it this weekend. I'm imagining that we'll have to expose the new grow functionality. I'll also have to see how the filesystem block_count autodetection is compatible with esp-idf's partition concept. Would be happy to hear any thoughts.

so I started working on this. I can of course just upgrade the submodule to LittleFS v2.8.0, but integrating the new functionality is another thing.

primary questions:

  1. Most of this driver is based around esp-idf partitions and partition labels, this doesn't really lend itself well to lfs_fs_grow. A possible action is to grow a filesystem if an existing filesystem is smaller than the partition is inside. But, I'm not sure if this is a feature wanted by anyone. Would love input.

  2. Similarly, since a littlefs fs typically takes up a whole partition, there's not much to be gained from the block_count detection code.

So in short, for esp_littlefs, what kind of improvements are we looking for?

  1. It is indeed the function grow. Maybe not a widely used feature for many.
    We compile our own Arduino framework for project Tasmota This firmware is used by most people to replace the on stock closed source (cloud based) firmware. We use only a few standard builds (all 4MB partition scheme) for all espressif MCU types. During first boot we detect the real size of the flash and increase the Filesystem. Currently we do this by making the Filesystem invalid so that a reformatting is done by LittleFS. The changed partition scheme is updated by the firmware. It would be nice not to loose the Filesystem content.
    Furthermore we do have our own OTA update system, which uses async OTA slots. The converting to this partition scheme is down from the firmware during runtime. One advantage, the FS can be bigger. With the new feature grow we could do the increase FS without loosing content.
    The flashed partition scheme is NOT fixed in our use case. LittleFS partition can be increased during runtime (by reducing the big OTA slot)

What we would need is an API for this which can be used.

Can you help me come up with the API? I've got two possible ideas

Idea 1: Explicit grow

An an explicit grow function. The function name will have signature like:

esp_err_t esp_littlefs_grow(...);

But what should the parameters be? Maybe:

esp_err_t esp_littlefs_grow_partition(esp_partition_t *partition);

where an exisitng littlefs filesystem has to exist at the partition, and it will grow to the size of the partition?

Idea 2: Grow on mount.

We add a configuration flag to esp_vfs_littlefs_conf_t:

uint8_t grow_on_mount:1;

Then, when esp_vfs_littlefs_register is called, esp_littlefs will attempt to autodetect the block_count of the existing filesystem. If it's smaller than the full size of the partition, then grow the filesystem.

Opinions

I personally like the second idea. I think it's easier and more intuitive for the user, and it's also less work for me ๐Ÿ˜„ . Would the second idea fit your use case?

Thx, for the fast response. Give me or better us, a bit of time to answer.
We have to discuss about. I hope I can answer in a few hours.

This is awesome!

For Tasmota the first step will be to detect that the FS partition is not maximized, then write a new partition layout and reboot. This reboot is mandatory anyways.

So it fully makes sense to do a "grow on mount" at the next boot. So second option is preferred for Tasmota as well.

closing this issue for now; additional conversations can be had in #148 .