Hello
This is quite a complete report with a lot of details, this shows that
you have put some large amount of mental energy in this project, so
congratulations and thank you.
What I'm about to write is not a critic but a complement that may
interest you.
Since I've worked with critical flash systems for more than 10 years
now, I have read the part of your document that deals with power loss
with great interest.
Resilience to power loss is *absolutely critical* to any embedded
filesystem.
Did you do power interruption tests on your code? Can you guarantee that
the device format stays consistent/recoverable when the power is cut at
any code location? Did you identify power critical code sections (with
relation to power cut, not cpu access) ?
Remember, if it's not tested, it doesnt work...
The most critical part of your work is the journal. Do you make sure
that the checksum is written 1-last, and 2-completely? How do you make
sure that the journal entries are correctly applied to their final
storage locations?
The largest problem in that area is flash metastability. The checksum
MIGHT appear correct on one read, but not correct at the next access.
The reason for this is the analog nature of flash writes (and erases),
which injects a number of electrons in a floating gate. 0 and 1 bits are
separated by thresholds, but these thresholds vary with temperature and
time (wear), so it might appear that a bit is correct by being just at
the threshold, but the next access will result in a flipped bit.
These issues are NOT theoretical, they happen all the time in all flash
devices, you just have to tickle the devices often enough at the right
moment so you begin to see these.
These tests require the ability to fully cut the power to a test board
with microsecond precision. No need for pulses, just an adjustable
delay. Test is triggered by a command that also start a countdown, and
timeout is increased microsecond by microsecond until you reach the
point that the flash is actually written. Usually, there is a point
where timeouts result in partial writes. Then the board will start
acting funny and will start entering the error branches that are usually
never taken. Board capacitors are not a problem, they just increase the
delays. They always discharge the same way during all repeated tests, so
they have no influence on the process.
It is quite hard to make sure that everything is correct, but a
sufficient amount of dedication is required to be aware of the potential
problems.
How do you know in your filesystem that the checksum has been written
only after all the previous data are written? How do you know the
checksum write is complete. There are software techniques for this. This
also requires the flash to support overwrites, so making this work with
ECC is harder (but possible).
Fine details absolutely matters here.
Thanks,
Sebastien
On 12/09/2024 17:48, Saurav Pal wrote:
Hi all,
Here's my final report <https://resyfer.github.io/blogs/mnemofs/endeval/>
on mnemofs, a NAND flash file system for NuttX, on which I worked during my
tenure as a GSoC 2024 Contributor for ASF. I would be grateful for any
suggestions and criticism.
Best regards,
Saurav Pal.
