Hi Tomek, I think it is possible to modify the NAND Simulator to help testing partial writes and induced errors.
But I agree with Sebastien that it is better to test in real hardware. Since the MnemoFS already works in the simulator we can get the initial version working in any flash, even SPI NOR Flash. BR, Alan On Fri, Sep 13, 2024 at 10:05 AM Tomek CEDRO <to...@cedro.info> wrote: > very nice discussion! > > can problems with NAND create a semi-dereministic group of well defined > issues with random characteristics? > > if so then we could create a model nand for sim with controllable errors in > order to verify various nand drivers, filesystems, etc? > > :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Fri, Sep 13, 2024, 14:52 Alan C. Assis <acas...@gmail.com> wrote: > > > Hi Sebastien, > > > > Thank you for your helpful considerations. > > > > As I explained before he used the SIM NAND Simulator that he created and > > integrated on NuttX. > > > > Also as I explained in my previous email, we need help to test in real > > hardware. > > > > Since you have previous experience with NAND Flash, maybe you could help > > here (of course, if you are interested to help)! > > > > First we need to create a driver for a SPI NAND Flash (I bought this > model: > > https://aliexpress.com/item/1005005307786079.html) and use it with > > MnemoFS. > > > > This model that I selected has internal error detection, etc, it means we > > don't need to worry about taking care of bad blocks ourselves. > > > > If you look inside nuttx/drivers/mtd/ many of the pieces we need are > > already there, we just need to understand how to use SPI NAND, FTL, MTD, > > etc. > > > > Xiang, since you and your team ported YAFFS to NuttX, maybe you guys > could > > help us to get MnemoFS working on real flash on NuttX. > > > > BR, > > > > Alan > > > > > > > > On Fri, Sep 13, 2024 at 6:17 AM Sebastien Lorquet <sebast...@lorquet.fr> > > wrote: > > > > > 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. > > > > > > > > > >
