littleFS disadvantages?

[dgerman]

After reading https://forum.pycom.io/topic/5922/an-alternative-to-nvram_save-restore-using-the-sd-card
I got concerned about FileSystem wearing since I have been writing a log file for debugging to FATFS /flash.
Reading https://github.com/ARMmbed/littlefs make me think I (we all) should be using littleFS.

1. Is there any reason not to use littleFS?
2. Is there a way to inhibit updating the file timestamp? Since I include the time in the log entries the timestamp on the file uses unnecessary writes.
3. Is there a way to tell the level of wear?
4. Is changing the FIleSYstem as simple as "pycom.bootmgr(fs_type=pycom.LittleFS)"

os.uname()
(sysname='GPy', nodename='GPy', release='1.20.2.rc2', version='v1.11-605f40f on 2020-02-04', machine='GPy with ESP32', pybytes='1.3.1')

[techykermit]

@robert-hh Sounds great, thanks for the help!

[robert-hh]

@techykermit I made an endurance test with littlefs, writing a file 5 Million times. That worked well. The last version of the Firmware enabled protection against flash wearing. So take care to use the recent version.

[techykermit]

Hi there!

We're thinking about eventually changing our production units to LittleFS since we have had multiple issues with devices losing code after a brownout. One year later, what does the stability with LittleFS with PyCom look like? We're building our firmware from source (cloning pycom-micropython-sigfox). From what I can see, the HiveEyes improvement related to LittleFS instability that @andreas mentioned has been merged into source? Our tests so far with LittleFS have not shown any issues.

[andreas]

Dear @dgerman,

Is there a way to inhibit updating the file timestamp [to prevent unnecessary writes]?

Not that I am aware of. You would have to change the baseline firmware on the C-Level.

Following [1], you might want to update (comment out) some code within [2] to see if this gives you any performance gains on that topic. I don't believe it will be made optional by any means through an official release, so you will have to bake a custom firmware image.

However, as [3] shows it is essentially just a matter of invoking memcpy on the file configuration struct on ordinary write operations, it seems to be different to what we know from regular Linux systems that updating mtime will have any performance overhead.

With kind regards,
Andreas.

[1] https://github.com/pycom/pycom-micropython-sigfox/pull/413
[2] https://github.com/pycom/pycom-micropython-sigfox/blob/6d01270/esp32/littlefs/vfs_littlefs.c#L280-L334
[3] https://github.com/pycom/pycom-micropython-sigfox/blob/6d01270/esp32/littlefs/vfs_littlefs.c#L385-L398

[dgerman]

@Andreas Thanks for your detailed and informative reply.
Might my idea regarding suppressing timestamp updating be included somewhere as a new feature?

[andreas]

Dear @dgerman,

FatFS is known to corrupt the filesystem in brownout conditions [1], please use LittleFS. However, the LittleFS implementation of the official releases has some bugs, so we want to humbly direct you to our Squirrel firmware builds [2], which mitigate some important issues.

Running that on our devices, we are pretty much satisified regarding overall runtime stability and robustness and have already been able to help others in this matter.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/fipy-verliert-programm-nach-power-off-durch-leeren-lipo-file-system-corruption-through-brownout-conditions/2057
[2] https://community.hiveeyes.org/t/squirrel-firmware-for-pycom-esp32/2960

---

P.S.: Regarding your other questions:

2. Is there a way to inhibit updating the file timestamp? Since I include the time in the log entries the timestamp on the file uses unnecessary writes.

Not that I am aware of. You would have to change the baseline firmware on the C-Level.

3. Is there a way to tell the level of wear?

I don't believe so. However, others might have more insights on this matter.

4. Is changing the FIleSYstem as simple as "pycom.bootmgr(fs_type=pycom.LittleFS)"

We are using a make target like make format-flash, which essentially boils down to

import uos, pycom
pycom.bootmgr(fs_type=pycom.LittleFS, reset=True)
uos.fsformat("/flash")

[kjm]

Amazing that individual experiences can be so different Robert. My gpy was forever defaulting my deepsleeping boot.py back to the factory default null program till I swapped to LittleFS @ release 1.20.1.r1

[robert-hh]

@dgerman After changing the FStype in bootmgr, it's best to reinstall the firmware with the option to erase the file system first. That way you have a clean start. Just changing the type & restart may also be possible. I tested that once, but I forgot the result.
From personal experience I cannot recommend using LittleFs, at least not in combination with ftp. I had quite a few system crashes and file corruptions with that. As far as I could tell, there are still memory allocation problems in LittleFs. FAT is rock solid.