31–40 of 74 posts
Afaict checksums only cover metadata and it doesn't do any read integrity checking, isn't that bad when talking to raw flash devices since it relies on them accurately reporting errors?
I wonder if that was intended to be done by the user at file level.
Earlier quoted context omitted.
I was talking about checksumming, not error correction. Since the meta-data blocks are already covered by CRC32 I wonder why the data blocks aren't.
Error correction provides the same value as a checksum, but better. (the tradeoff is ECC codes are much larger and more expensive to compute) It's also worth noting the CRC is used for power-loss and doesn't actually provide error detection for metadata-blocks. Checksumming data is a bit complicated in a file system, mostly because of random file writes. If you write to the middle of a file, you will need to update a…
That's not an issue in CoW filesystems since you need to write out the whole modified block. You might as well hash it.
Afaict checksums only cover metadata and it doesn't do any read integrity checking, isn't that bad when talking to raw flash devices since it relies on them accurately reporting errors?
That's mentioned towards the end of the link: > littlefs by itself does not provide ECC. The block nature and relatively large footprint of ECC does not work well with the dynamically sized data of filesystems, correcting errors without RAM is complicated, and ECC fits better with the geometry of block devices. That is, ECC and read-integrity checking is determined at the block level, not the filesystem level. The fi…
Wear-leveling delays wear errors until the end of the device's life. Once these start to develop you will eventually have storage that's unusable. The cheapest option may be to just let the device crash when it has reached end-of-life.
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.
Assuming you only need to execute one Flash transaction (doubtful!), covering all of the variation might take upwards of 50ms.
So, yeah, you could just throw a massive cap on the power rail. Except that that conflicts with the other power, cost and size constraints implicit in the context of microcontroller systems.
Given that, I don't understand the discussion of wear leveling in this FS. Maybe someone can explain further.
Earlier quoted context omitted.
Also why not chuck a capacitor in the mix to provide a little power buffer to shutdown the filesystem gracefully.
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.
"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.
In one project I worked on we monitored the 24V rail and when it was dropping, the MCU had enough time to do cleanup /shutdown work until the 3.3V supply dropped.
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.
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.
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.