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

41–50 of 74 posts

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

#41

Post by nine_k »

neltnerb wrote: post #30
ianhowson wrote: post #27

Earlier quoted context omitted.

Except that: (a) you don't choose how long you get because the uC manufacturer already chose. (An external brownout warning is different, and useful, but still not a good solution to the problem of FS integrity.) (b) those thresholds have nothing to do with the operating thresholds of the flash (which usually require a lot more energy to do work than the uC) (c) writing to flash is a relatively high-power operation,…

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.

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

#42

Post by kabdib »

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.

Brownout detection isn't sufficient. There are many other sources of "instant stop", from simple hard-crash bugs to bit-flips in RAM that either cause a crash or multiple-bit ECC fault, take your pick because they will all turn out the lights without warning.

For consumer devices there's ESD testing, where devices are subjected to several kilovolts of zap in certification tests and are required to survive. Typically this means the device will reset and recover, but it needs to be in usable condition afterwards. If a surprise reset results in a toasted file system and a brick, you won't be able to sell the device in markets that require this testing, which is most of Europe and (I think) the US.

The right way to do a persistent store is to expect the lights to go out on any arbitrary bus cycle and design around that.

I've written a few of these. They're fun.

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

#43

Post by neltnerb »

neltnerb wrote: post #30
ianhowson wrote: post #27

Earlier quoted context omitted.

Except that: (a) you don't choose how long you get because the uC manufacturer already chose. (An external brownout warning is different, and useful, but still not a good solution to the problem of FS integrity.) (b) those thresholds have nothing to do with the operating thresholds of the flash (which usually require a lot more energy to do work than the uC) (c) writing to flash is a relatively high-power operation,…

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…

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 resistor R4 provides hysteresis -- after the P-channel MOSFET activates it acts to keep the N-channel MOSFET active unless the voltage drops below some level set by R2, R3, R4, and the turn on voltage of Q1. You just need to tune them appropriate for your components, and granted of course it adds some amount a bit to your BOM cost. But if you need it you need it.

So basically, R2/R3/Q1 set your turn on voltage (experimentally determined or maybe with Spice) and R4 sets your turn off voltage with R2/R3/Q1. The MCU probably uses under 500mA so these parts are pretty cheap... the capacitor is about 5 cents (https://www.digikey.com/product-detail/en/kemet/ESK477M6R3AE...) and the MOSFETs that looks appropriate are in the 6 cent each range.

https://i.postimg.cc/Df9N8fM5/delayed-turn-on-circuit.png

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

#44

Post by neltnerb »

leggomylibro wrote: post #36
delfinom wrote: post #21

Earlier quoted context omitted.

Many MCUs do not appreciate slow rise-times when using their internal regulators. Then you start oversizing your regulator or providing them replacement regulators. Which then opens more cans of worms, etc, etc.

Many voltage regulators have 'power good' pins that you can tie to the MCU's reset line, though.

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.

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

#45

Post by varjag »

kabdib wrote: post #42
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.

Brownout detection isn't sufficient. There are many other sources of "instant stop", from simple hard-crash bugs to bit-flips in RAM that either cause a crash or multiple-bit ECC fault, take your pick because they will all turn out the lights without warning. For consumer devices there's ESD testing, where devices are subjected to several kilovolts of zap in certification tests and are required to survive. Typically…

My understanding was if the function is interrupted on discharge, you fail the test. At least that's how our equipment was tested by an independent lab.

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

#46

Post by benlwalker »

kabdib wrote: post #39
benlwalker wrote: post #35

All of the flash SSDs I am familiar with have no fixed relationship between a logical block and the actual NAND media backing it. In other words, the device automatically wear levels internally and the only control the user has over wear is the total number of writes they perform. Given that, I don't understand the discussion of wear leveling in this FS. Maybe someone can explain further.

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, eventually that block will wear out. Filesystems that don't take wear into account can easily burn through blocks used to store frequently updated metadata and cause a device's early death."

This isn't true. It's only true for filesystems that aren't running on a regular block storage device. It's even more egregious to use the word block because almost everyone assumes that means a logical block. They must be using it to mean a NAND page, which has entirely different behavior and does wear out.

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

#47

Post by kabdib »

varjag wrote: post #45
kabdib wrote: post #42

Earlier quoted context omitted.

Brownout detection isn't sufficient. There are many other sources of "instant stop", from simple hard-crash bugs to bit-flips in RAM that either cause a crash or multiple-bit ECC fault, take your pick because they will all turn out the lights without warning. For consumer devices there's ESD testing, where devices are subjected to several kilovolts of zap in certification tests and are required to survive. Typically…

My understanding was if the function is interrupted on discharge, you fail the test. At least that's how our equipment was tested by an independent lab.

Might be different depending on the market. For us it was "we can reset, but we have to recover within a few seconds". I never questioned the wisdom of our hardware cert engineers.

(My experience at three different companies spread over 35 years was, if you were a software engineer helping the hardware types with ESD or RFI testing in the lab, you were definitely going to get zapped at some point. That made you part of the team, though ... :-) )

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

#48

Post by xondono »

neltnerb wrote: post #30
ianhowson wrote: post #27

Earlier quoted context omitted.

Except that: (a) you don't choose how long you get because the uC manufacturer already chose. (An external brownout warning is different, and useful, but still not a good solution to the problem of FS integrity.) (b) those thresholds have nothing to do with the operating thresholds of the flash (which usually require a lot more energy to do work than the uC) (c) writing to flash is a relatively high-power operation,…

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 lot of time is way easier and more reliable to have a secondary battery (Li coin cell) for this kind of purpose.

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

#49

Post by xondono »

craftinator wrote: post #28
ianhowson wrote: post #27

Earlier quoted context omitted.

Except that: (a) you don't choose how long you get because the uC manufacturer already chose. (An external brownout warning is different, and useful, but still not a good solution to the problem of FS integrity.) (b) those thresholds have nothing to do with the operating thresholds of the flash (which usually require a lot more energy to do work than the uC) (c) writing to flash is a relatively high-power operation,…

But you can just... Decide how many clock cycles you'll need to finish shutdown, calculate that power usage, then solder a corresponding power source in place. There really isn't guesswork.

In some situations this might be an unsolvable equation.

If your power supply is already 1.8V, most uC will not have much room for procedures when a POR/BOR is detected.

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

#50

Post by leggomylibro »

neltnerb wrote: post #44
leggomylibro wrote: post #36

Earlier quoted context omitted.

Many voltage regulators have 'power good' pins that you can tie to the MCU's reset line, though.

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.

Oh, neat trick - thanks for sharing!
Post reply on HN