LittleFS: A New File-System For ARM Embedded Devices

[phoronix]

Phoronix: LittleFS: A New File-System For ARM Embedded Devices

LittleFS is a lightweight file-system that's being developed for embedded systems...

http://www.phoronix.com/scan.php?page=news_item&px=LittleFS-ARM-Embedded-FS

[deadite66]

relevant link for those wondering about the story image.

[rene]

can't ever have too many file systems, ...

[aksdb]

can't ever have too many file systems, ...

Name another one that can fit in only a few kBytes of FLASH and only bytes in RAM while handling sudden power-off and dealing with low level EEPROM/Flash access (i.e. without any firmware for wear leveling etc.).

[zamadatix]

Name another one that can fit in only a few kBytes of FLASH and only bytes in RAM while handling sudden power-off and dealing with low level EEPROM/Flash access (i.e. without any firmware for wear leveling etc.).

JFFS2/YAFFS2 have been in use for around 15 years now for this exact purpose, it's not like the challenges you listed are new to 2018 embedded devices just because"IoT" was thrown in front of their names.

[aksdb]

JFFS2/YAFFS2 have been in use for around 15 years now for this exact purpose, it's not like the challenges you listed are new to 2018 embedded devices just because"IoT" was thrown in front of their names.

From what I see, the author specifically looked at jffs and yaffs and didn't like them for embedded use cases. A read of the DESIGN document is worth it.
At least from a quick google search I couldn't find any use of jffs2 in embedded devices. For yaffs there is apparently a port but released under GPL which makes it kinda pointless (I at least don't see any device manufacturer releasing their actual device firmware as opensource ... and neither would my employer or our customers ;-))

[zamadatix]

From what I see, the author specifically looked at jffs and yaffs and didn't like them for embedded use cases. A read of the DESIGN document is worth it.

I read through that, the author basically said JFFS/YAFFS cover the goals except for scaling where they say: "However, logging filesystems have a difficulty scaling as the size of storage increases. And most filesystems compensate by caching large parts of the filesystem in RAM, a strategy that is unavailable for embedded systems.". This is true once you hit ~the gigabyte range, yet at the start of the design document the author says "The embedded systems the littlefs is targeting are usually 32 bit microcontrollers with around 32KB of RAM and 512KB of ROM. These are often paired with SPI NOR flash chips with about 4MB of flash storage.". This is nowhere near the scaling limit and JFFS/YAFFS, the only given reason they were not suitable.

At least from a quick google search I couldn't find any use of jffs2 in embedded devices.

Routers are (well, more "were" nowadays) the big case you'd find, but really anything... it's just not often embedded device manufacturers advertise the filesystem on the flash they used .

For yaffs there is apparently a port but released under GPL which makes it kinda pointless (I at least don't see any device manufacturer releasing their actual device firmware as opensource ... and neither would my employer or our customers ;-))

There is a commercial license offering for Yaffs as well but this is a moot point, if you're building a filesystem driver from scratch there is no requirement it must be for a brand new filesystem.

[DrYak]

From what I understand, they are targetting micro controllers.

Think "Arduino-like boards" instead of "Linux-powered embed routers".

The latter are successful use cases of JFFS and co (have "plenty" of RAM and ROM, at least on the scale of embed devices).
The former might hit the limitations of JFFS and co, specially if you pair them with big storage (e.g.: for low power sensors in remote locations, where you can't constantly uplink to some Raspberry Pi running a full blown distro for the sensors data storage.)

The main problem of logging file systems (JFFS, YAFFS, F2FS, UDF, etc.) is that they don't actually store the filesystem per se, but only store a list of successive modifications (log) of the files inside an imaginary file system. That does wonder to the wear levelling (you're basically just adding new entries sequentially to the log, and only eventually garbage collecting older sections that aren't relevant anymore). But it means that you have to actually keep track of the whole log to know where to look for a file ("use some rather... opportunistic... techniques, such as reconstructing the entire directory structure in RAM." according to LittleFS author).

So instead, the author went for a structure closer to Copy-on-Write (BTRFS, ZFS) - where data is never over written, only newer version are written and the pointer updated, with some clever, a little bit more log-like techniques thrown in for the "pointer update" part (the metadata) to be more powerloss resilient and less wear-stressing on non-managed flash.