On Wed, Mar 1, 2023 at 8:43 PM Alan C. Assis <acas...@gmail.com> wrote:
> Hi Xiang Xiao, > > This is a great news, but I'm afraid yaffs is not a good option for > everybody because it uses GPL license. > > Yes, but you can pay some money to switch to a more friendly license. > But yes, it could be an option for people and companies that can > release all their software as open-source. PX4 project for example > could use it. > > The enhancement in mtd_s is decoupled from yaffs, actually the new interface follows Linux MTD model. BTW, We plan to improve LittleFS to utilize the new interface. > BR, > > Alan > > On 2/28/23, Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > We are working on yaffs porting, mtd_s need a little bit of extension to > > support NAND flash. > > Here is the patch: https://github.com/apache/nuttx/pull/8670 > > LittleFS needs some modification to get the benefit. > > > > On Sun, Feb 26, 2023 at 10:14 PM Nathan Hartman < > hartman.nat...@gmail.com> > > wrote: > > > >> On Sat, Feb 25, 2023 at 8:53 AM Gregory Nutt <spudan...@gmail.com> > wrote: > >> > >> > > >> > > Maybe LittleFS or SmartFS could be extended to handle NAND. > >> > > >> > I believe that LittleFS has been used with NAND with a NAND FLASH > >> > translation layer. I am not sure of the state of that work, but I > know > >> > that people have tried it. Google "LittleFS on NAND flash" and see > the > >> > hits. > >> > > >> > If a NAND flash translation layer (NFTL) were ported to NuttX, then > you > >> > should be able to use almost any file system, although some would be > >> > extremely inefficient with NAND. The NAND flash layer would need to > do > >> > sparing, wear-leveling, ECC calculations, etc. as needed by NAND. > >> > > >> > I have used NXFFS with NAND and it /almost /works. > >> > > >> > The basic filesystem issue is that all available filesystems need to > do > >> > read-modify-write operations on flash sections. And they assume that > >> > you can always write a '1' bit to a '0' bit. SmartFS and NXFFS both > >> > assume this behavior explicitly. It is a good assumption with NOR > >> > flash. The problem is that NAND can only be written a whole sector at > >> > a > >> > time. This is because the error correction coding (ECC): If you > >> > change > >> > even one bit in the NAND sector, you have to re-write the whole sector > >> > with new ECC (because you can't change the '0' bits in the ECC back > >> > into > >> > '1''s without erasing the sector). > >> > > >> > Since SmartFS and NXFFS both do bit twiddling in the sectors they > would > >> > be very inefficient with an NFTL: Each bit twiddle would cause a > whole > >> > sector re-write. The same is probably true for LittleFS. Other file > >> > systems like FAT could also be used if there were an NFTL, however, > FAT > >> > would also be inefficient (each directory update or FAT update and > each > >> > file data size change would cause another sector write). > >> > > >> > So the only real solution to support NAND efficiently is use a file > >> > system that is designed specifically around the peculiarities of NAND. > >> > That would require some research (Alan has suggested a couple of > places > >> > to start). > >> > >> > >> > >> I seem to recall reading that in NAND flash, one of the challenges is > >> that > >> modifying a bit causes a disturbance that can corrupt other bits, even > in > >> unrelated sectors, and that even reading can have this effect. The > >> disturbance only affects bits a little at a time, but after some number > >> of > >> accesses, the affected sectors need to be written to new sectors, > keeping > >> track of bad sectors formed in the process, to avoid data loss. This may > >> lead to a cascade effect in which reading a sector may cause numerous > >> sectors to be re-written. This phenomenon is called write amplification. > >> The takeaway from a usage perspective is that you want to over-provision > >> the amount of NAND flash you install, to leave plenty of room for all > >> this > >> swapping, and plenty of extra sectors to increase the amount of accesses > >> before failure. The greater the over-provisioning, the longer until > >> failure. > >> > >> I haven't tried yet, but I would like at some point to support a > micro-SD > >> and/or micro-MMC card as the backing store and use one that has built in > >> hardware wear leveling, with some appropriate file system of course. > This > >> may add $50 or more to the bill of materials depending on the card > >> capacity, but makes it possible for users to replace the card if it > >> fails, > >> in contrast to soldered-on flash chips, which can be replaced too, but > >> only > >> with the appropriate tools and skills. > >> > >> Cheers > >> Nathan > >> > > >
