Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The design of littlefs: A fail-safe filesystem designed for microcontrollers

github.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#61

Post by kabdib »

pantalaimon wrote: post #9
kartoffelwaffel wrote: post #7

Earlier quoted context omitted.

Also why not chuck a capacitor in the mix to provide a little power buffer to shutdown the filesystem gracefully.

It adds quite some space and probably costs as much as the MCU.

Yeah, paying thirty cents for a capacitor to coddle a ten-cent MCU doesn't make a bunch of sense. Much cheaper to teach your software folks how to write transactional updates to that flash. Typically you pay a small speed penalty to get update atomicity (in addition to having a more complicated implementation).

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#62

Post by jdub »

oscargrouch wrote: post #56
_urga wrote: post #18

> Logging filesystem are beautifully elegant. With a checksum, we can easily detect power-loss and fall back to the previous state by ignoring failed appends. An edge case when designing a log-structured file system is that a corrupt checksum in a log entry could actually mean one of three things: power loss while writing the last transaction, a misdirected write or bitrot, or a misdirected read. If you simply read t…

This is not my field of expertise, so forgive me if im mistaken, but isnt 'Ohad Rodeh B-trees'[1] a simple and more elegant solution than a journal/WAL? As far as i know its already used in Linux Btrfs and in LMDB, and i wonder why, if they were designing this from scratch, why they didnt go for this in the first place. Familiarity perhaps? By the way i have code that deals with the SQLite Btree directly and by readi…

The article explains why tree structures were inappropriate for the use case.

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#64

Post by neltnerb »

Tempest1981 wrote: post #54
neltnerb wrote: post #44

Earlier quoted context omitted.

And if you don't have this, I posted this circuit example I just made for a delayed power turn on time above. Capacitor is about 5 cents, the transistors are about 6 cents each. If you need it you need it, but power good to the reset line is better. https://i.postimg.cc/Df9N8fM5/delayed-turn-on-circuit.png Or just put a capacitor after the reset line pullup so that it effects delayed turn on during boot.

What is the voltage drop across D1 and Q2? Is that ever an issue?

The drop across D1 can be significant, using a Schottky helps. Usually within the tolerance of the power supply in any case.

But a capacitor on the reset pin is pretty good ;-)

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#65

Post by geky »

benlwalker wrote: post #46
kabdib wrote: post #39

Earlier quoted context omitted.

No SSDs here, this is raw flash. This is the wear leveling layer.

I assumed so, but then why all the comparisons to file systems that are designed to run on top of a flash translation layer? I would have expected something in big bold letters at the top saying this is designed to run without an FTL, whereas the other filesystems rely on one to wear level. For example, this is right at the top: "Writing to flash is destructive. If a filesystem repeatedly writes to the same block, ev…

Honestly most file systems haven't been designed to run on an FTLs (except maybe UBIFS). Most filesystems have been designed to run on magnetic disk drives, where wear is a non-issue and data locality is more important.

As the world transitions to flash, FTLs were created to translate flash in a way that doesn't require rewriting the filesystem. But this adds a layer of abstraction that can make the resulting storage stack more costly than is necessary.

Why the comparison to traditional, magnetic disk based filesystems? Because a lot people are putting them on raw flash and expecting them to work (mostly FAT in the MCU space). It's important to inform their perspective that traditional storage practices don't work on raw flash.

As for everyone assuming block == logical block, I don't think that's true. It's a pretty overused term, in NOR/NAND datasheets it simply describes the physical geometry of the raw flash. Though even there it is inconsistent.

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#66

Post by garganzol »

technothrasher wrote: post #6

"Usually, microcontroller code is simple and reactive, with no concept of a shutdown routine." Really? Nobody uses brownout interrupts to lock down on power loss? I almost always do a few things as the power is fading, flagging the situation at the very least in order to clean up when power is restored.

My usual design is to monitor AC powerline with opto-coupler and then enter the brownout procedure in MCU when the power loss is detected. The remaining energy stored in AC/DC converter capacitors are then used for a graceful shutdown purposes.

The usual brownout procedure actions are: a) flush the current state to MCU flash memory (EEPROM) so that the work can be automatically resumed; b) wait for a power-on condition.

In this way, the device is able to significantly reduce flash memory wearing. It turns to be a significant winning factor in cheaper MCUs, as they only allow about 100,000 EEPROM write cycles max.

And it comes for cheap, as the only thing you need is an opto-coupler plus a bit of software wizardry.

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#67

Post by fanf2 »

geocar wrote: post #15

> and the unfortunate fact is you can't traverse a tree with constant RAM This is not true. See Knuth, The Art of Computer Programming Vol.1, § 2.3.5). Generally I wouldn't recommend naive SDW as a good strategy for filesystems, but if you have a fixed number of processes (common in microcontroller applications) it might be worth trying.

Pointer swizzling tree traversal requires writes to the tree which isn’t possible in this case.

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#68

Post by kevin_thibedeau »

londons_explore wrote: post #58
neltnerb wrote: post #43

Earlier quoted context omitted.

Another reply mentioned that many MCUs don't like it when power is applied too slowly. Here is a version I just made as an example that uses two MOSFETs and a resistor divider to delay application of power to the MCU and flash memory. It relies on the N-channel MOSFET turn on voltage along with the resistor divider to set the turn on voltage, and when it reaches the threshold the P-channel MOSFET turns on. Note the r…

Most mcus are fine with power being applied slowly as long as they have a separate reset signal. It's good practice to have a separate reset signal anyway, to avoid unintended behaviour while the circuit is powering up.

You are still asking for trouble. Once something goes into latchup, reset is unlikely to recover. If not the MCU, then some peripheral on the same supply may express it's dislike for intermediate voltages.

Re: The design of littlefs: A fail-safe filesystem designed for microcontrollers

#70

Post by ClumsyPilot »

nine_k wrote: post #41
neltnerb wrote: post #30

Earlier quoted context omitted.

I don't personally usually bother, but an EE approach would be to put a diode between the 3.3V supply and the MCU/flash power supply pins with a large bulk capacitor, and use the voltage just before the diode as your brownout detection. It can't discharge back into the power supply or other parts on the board because of the diode so the capacitor just needs to store enough charge to run for a specified time after pow…

A compact and reliable 470 uF capacitor could cost comparable to to a low-end uC.

I mean, you get what you pay for. If your are cost-optimising that hard, you probably aren't controlling something with critical data.
Post reply on HN