Hi Greg
I totally agree with you. I'll save the hints here and see what I can do. At 2020-03-12 21:05:41, "Gregory Nutt" <spudan...@gmail.com> wrote: > >> 2.FTL for FAT ? >> >> It’s very nice to use FAT and FTL. I know FAT has a index table to mapping >> logical and physical area. But there is one problem Where should I put it ? >> >> If you put it in Nand Then this area may ware out, if you put in ram then >> when should it be synced to Nand and how often is suitable ? > >FAT should work fine with an appropriate FTL layer. The wear-leveling >will assure that all physical FLASH blocks receive the same amount of >wear even thought the usage of logic blocks is not at all even. If the >wear on the allocation tables gets high, the FTL should replace it with >a block that has lower were. > >A good NAND FTL layer should also detect any read or write errors and >spare that bad block, replacing it with a free block. > >FAT itself keeps backup allocation tables (although I don't think that >the NuttX implementation is capable of using them). > >However, I don't think I would recommend FAT even with the appropriate >FTL layer because I would suspect that the FTL overhead for frequent >leveling and sparing of the allocation table might high. > >> what if my device unexpectedly shutdown and lose all updated index ? >> Obviously SD-card or SSD supplier has their solution in their firmware but I >> don’t have it. >FAT is better than some file systems in that it only occasionally >trashes the file structure. If files are left open, then buffered, >unwritten data will be lost however. >> 3.Journal filesystem advantage. >> >> Journal filesystem with some node data in the nand page or in the spare area >> is robust, it has no central index table to avoid wear out and safe for >> unexcepted shutdown, >> >> Next time you power up, filesystem scan all data node and make a new ram >> structure. And it naturally support ware-leveling. > >TizenRT uses a very old port of NuttX (although they do bring in fixes >and updates from the NuttX mainline). Samsung has modified the version >of SmartFS that they have to include journaling: >https://github.com/Samsung/TizenRT/tree/master/os/fs/smartfs > >This is controlled the selections in the Kconfig file of that directory >(see below). > >Now both NuttX and TizenRT share an Apache license, so it should be >possible to bring this journaling feature into NuttX if you are so >inclined. I am not sure about grant-related issues. Apache may have >some addition requirements to make that more difficult. > >Greg > > config SMARTFS_JOURNALING > bool "Enable filesystem journaling for smartfs" > default n > ---help--- > Enables logging of write operations on filesystem, > so that in > case of power failure the filesystem can be brought > to a stable > state with minimal data loss. > Enabling journaling will increase the delay in > filesystem > operations, because before doing any fs operation, > journaling > will first log it in journal area. The journal area > will also > take up space in the flash, leaving lesser space > for filesystem. > The space reserved for journal area is proportional > to max number > of file descriptors allowed and sector size > defined. Thus, to > minimize the area reserved for journaling, it is > advised to keep > sector size small. > > if SMARTFS_JOURNALING > > config SMARTFS_JOURNAL_VERIFY > bool "Verify Journal logging" > default n > ---help--- > The read & verify joural value after right > Sometimes electronic power grow up after power off, in this > case > FS decide write finished properly, but it doesn't finished > properly. > To prevent this, verifying needed. > On the other hands, it takes more time for most of file > operation that > using journal Logging. > endif > > config SMARTFS_SECTOR_RECOVERY > bool "Enable recovery of lost sectors in Filesystem" > depends on MTD_SMART > default n > ---help--- > Enables recovery of lost sectors after power failure. Lost > sectors are the sectors which are allocated but not reachable > from root directory. > > endmenu > >
