What are folks using for reliable file system on for example SST26VF064B 64Mbit SQI flash?
Naive FAT will quickly wear out device for some uses; needs a wear-leveling file system.
Needs to be power-off safe as well; no corrupted file system from arbitrarily-timed power cut.
Anybody?
Thanks,
Best Regards, Dave

PS: A customer of ours used a commercial product called TINY some years back. It is unfortunately neither very well performing nor stable; led to product recall because it didn't properly wear-level
and flash devices failed...

Clarification: Application is a microcontroller with 512kb RAM; not as resource-constrained as many embedded products. FreeRTOS.

It of course depends of the OS that is running on the device that uses the flash, for example on Linux, there are massive amounts of FS that are designed with reliable flash usage in mind: 

From the venerable JFFS2 and its YAFFS2 contender to the UBIFS and experimental LogFS.

Of course, with the same importance is the analyze of use case, to determine which of this specialized FS are the best for the specific case, because, as always, they are not created equal.

Sadly many RTOS are really barely implementing FAT in the most pathetic way, much less with wear leveling and reliable operations, very few of them actually have R/W flash file systems with wear leveling, the best just are using the SD cards or EMMC memory internal algorithms and this is it.

An "bare metal" embedded programmer has a lot to do to get such a filesystem, I have actually rescued lots projects that were using the famous public domain ultra-naive FAT implementation and wondering why their flash and SD cards were gone in a couple of months of usage. Also had a good laugh of the hare-brained proposed band-aid solutions.

But in the end, the best flash file system can only load each block/sector equally in the attempt of leveling the number of writes on them, that is not so big to begin with (on the COTS flashes). A real well designed device has options to back-up the data to avoid a catastrophic failure, but the disposable junk done nowadays doesn't have this as a priority and having the product dead 3 months after warrany expires is considered a valuable feature.

 Cheers,

 MirceaC

MirceaC wrote "Sadly many RTOS are really barely implementing FAT in the most pathetic way, much less with wear leveling and reliable operations, very few of them actually have R/W flash file systems with wear leveling, the best just are using the SD cards or EMMC memory internal algorithms and this is it".

And sadly many MCU vendors provide tool-chains that do this! SD card isn't horrible but requires power management for reliability (power-down safety, both hardware and software) - which I haven't seen in the offerings I've looked at except for 3rd-part add-ons.

Hi,

Probably not only the software was faulty: a file system cannot be "power-off safe", fast and efficient at the same time, when the HW is not designed properly. If power off could cause half-written pages in the flash memory, every file system can get corrupted. (A half-written page does not mean that half of the data is 0xFF, it means that there are not enough electrons on the transistor gate in the memory cell and the voltage level of cell is too close to threshold level.)

In our file systems the requirement is that when power disconnected from the device, there must be enough power in the capacitors of flash memory to finish the last page programming and the software shall not start new page programming. The latter one can be achieved using brown-out detection.

Best regards,

Peter

Peter wrote "a file system cannot be "power-off safe", fast and efficient at the same time, when the HW is not designed properly."

Sure it can, for example a journaling FS with checksums. Obviously at some cost of performance and space, which is why I'm asking what other folks are currently using...

Yes, brown-out detection and extra power protection on the flash are best.

There is some misunderstanding: you cannot recover data using checksums. You can only determine that data is good or bad. That is the problem with a half-written page: it seems to be good, CRC is OK, but after a few weeks/months data start degrade. The data retention in the datasheets (usually several years) is only guaranteed when flash writing successfully finished.

Yup, got it...

Can't say how applicable: I've copied a block of flash to ram on power up, used ram for all uptime. At power down, a "fair" sized capacitor gives the uC time to copy back to flash. A special flag starts the block. At power up, check each block's flag, when you hit a blank, backup one for the most recent. Copy to ram and increment to next block address for power down. If most recent is last in flash, copy to ram, erase flash and reset the block write address to flash base.

You can go for FileX and LevelX. FileX will provide a FAT compatible file system (supporting anything from FAT12 to EXFAT) and LevelX will provide the wear leveling mechanisms.

I would suggest looking at Micrium's wear-leveling file system.  I know they have put a lot of effort into it. And, IIRC, it is DO-178 certified (uC/OS at DO-178B DAL A). Also meets the latest medical device standard (61508)

Scroll to the bottom if you need certs: https://www.micrium.com/rtos/rtos-comparison/

https://www.micrium.com/rtos/filesystem/ 

Trying to write your own is a non-trivial task. There are many pitfalls and arcane lore to doing it right. And you can use it if your stuff is non-commercial. If you *do* put it in a commercial product, then you need to get a license. However, Jean is a reasonable sort && I suspect you could cut a good deal with him.

https://www.micrium.com/buy/licensing/

(DIsclosure: I have used uC/OS off and on for 15+ years. I am not, nor ever been, an employee or otherwise had a business relationship.)