The obligatory file system question...

[SiliconWizard]

Yeah this is a recurring topic. But let's see if there are new things to learn/experience to share.

So, what are good file systems these days to consider for a small system? Primary storage would be Flash - either QSPI, or SD cards - and typical code size would be under 50 KB, with RAM size use under 32 KB or so.

Options I considered so far: FatFs, littlefs, Yaffs.

littlefs looked promising but I've heard a few bad things about it. Now if you have more to share...
FatFs has the benefit of making the storage - in particular if using SD cards - easy to read and write on any platform.
Yaffs looks good, but a bit high on resource use.

[bson]

I use FatFs.  It's very simple to implement, designed for resource-constrained 8088 PCs to begin with, and for a use case with specific limited needs often simplifies greatly.  For example, if you read config from it but only ever write logs and never delete anything, and only ever write one file (the current log), then sector allocation is a simple incremental operation and you don't even need to cache any portion of the FAT (the contents of any FAT sector becomes deterministic).  It's been a while, but there's a header value somewhere that effectively can be used to track the next available sector.  (If not there you will likely have to do a FAT scan at mount time.)  Just generate and write updated FAT sectors whenever needed.  This makes it easy to implement, easy to test, and very light on its feet.

[cfbsoftware]

Is 4868 *bytes* small enough?  We had to impose a few constraints to achieve this with HCFiler. It was inspired by the way mag tapes were used in the 1960's / 1970's computers

• On the embedded system the filesystem is write-only.
• Disk writes are purely sequential.
• Only one file can be open for writing at any one time.
• Once a file is closed it cannot be written to again.
• New files are always located immediately after the last file to be created.

For more info:
http://www.astrobe.com/forum/viewtopic.php?f=4&t=534

[nctnico]

I use FatFs.  It's very simple to implement, designed for resource-constrained 8088 PCs to begin with, and for a use case with specific limited needs often simplifies greatly.  For example, if you read config from it but only ever write logs and never delete anything, and only ever write one file (the current log), then sector allocation is a simple incremental operation and you don't even need to cache any portion of the FAT (the contents of any FAT sector becomes deterministic).  It's been a while, but there's a header value somewhere that effectively can be used to track the next available sector.  (If not there you will likely have to do a FAT scan at mount time.)  Just generate and write updated FAT sectors whenever needed.  This makes it easy to implement, easy to test, and very light on its feet.

I second using FatFs. I have no experience with the other filesystems mentioned but I have used FatFs in several projects with good results.

[eutectique]

The client I am working for now had selected littlefs for their products. All of them use FOTA, if that matters. Haven't spotted anything suspicious so far.

I'm curious, what bad things have you heard?

[SiliconWizard]

The client I am working for now had selected littlefs for their products. All of them use FOTA, if that matters. Haven't spotted anything suspicious so far.

Thanks for the feedback!

I'm curious, what bad things have you heard?

Like 1/ still a number of bugs making it not very reliable, and 2/ maintainer(s) not being very responsive. But this was not first-hand feedback, so your input is appreciated.

[SiliconWizard]

Use cases may be useful, because it's often all in the context.

So, at the moment I have to main types of use cases from the POV of the embedded system:
- Mostly read-only: requires a lot of reads, but infrequent writes. Most files read in this context will have been written to outside of the system itself;
- Mostly write-only: frequent writes (typical of data logging and/or recording, such as audio), but infrequent reads. Writes should be efficient but also minimally prone to corruption in case of power loss.

In the first case, any file system/implementation that is not efficient for writes is not a problem, but reads must be efficient. Conversely for reads and writes in the second case. So both cases could be handled by a different file system or implementation if needed.

[eutectique]

Like 1/ still a number of bugs making it not very reliable, and 2/ maintainer(s) not being very responsive. But this was not first-hand feedback, so your input is appreciated.

This is good to know.

The way we use LFS is not very stressful. Infrequent write and read of parameters, occasional FOTAs. Perhaps, not much chance to face an issue.

[SiliconWizard]

Like 1/ still a number of bugs making it not very reliable, and 2/ maintainer(s) not being very responsive. But this was not first-hand feedback, so your input is appreciated.

This is good to know.

The way we use LFS is not very stressful. Infrequent write and read of parameters, occasional FOTAs. Perhaps, not much chance to face an issue.

Really so far I have no personal, or at least direct feedback. But you may just have a look at the project on github and look at the issues and see what kind of issues there are and how they are handled by maintainers. I still suggest you do some stress testing on it to be on the safe side.

[JOEBOBSICLE]

I've done well with little FS before. You need to make sure you're doing large writes instead of bytes at a time.

 I'm not sure if the amount of GitHub issues is a sign of success or failure, if you want a power safe filesystem then I think this is your only free choice tbh.

[SiliconWizard]

Is 4868 *bytes* small enough?  We had to impose a few constraints to achieve this with HCFiler. It was inspired by the way mag tapes were used in the 1960's / 1970's computers

• On the embedded system the filesystem is write-only.
• Disk writes are purely sequential.
• Only one file can be open for writing at any one time.
• Once a file is closed it cannot be written to again.
• New files are always located immediately after the last file to be created.

For more info:
http://www.astrobe.com/forum/viewtopic.php?f=4&t=534

Well, given the use cases I mentioned - surely not for more general-purpose use - this kind of approach could actually be the way to go.

Years ago, I designed a small read-only FS for Flash memory and SD cards. Would be created with a PC tool. Worked quite well. It was 400 odd lines of C code (.c and .h included) and about 6 KB of object code size (for a 16-bit target), with data integrity checking. Without it, it would have taken significantly less.

Likewise, a "data logging" kind of FS could be relatively simple too if data / files are guaranteed to be written in sequence with a few constraints. You'd get wear leveling for "free" as well.

Although the opposite of general-purpose, those approaches are certainly usable in the appropriate contexts.

For more general-purpose use, FatFs is certainly on my short list. It's been widely used, is quite stable, and supports FAT/FAT32/exFAT - a bonus if you need easy data exchange. One concern though is that FAT file systems are not robust and get corrupted easily. There are ways to use FatFs to minimize your chances of corruption, but it's not ideal.

[brucehoult]

Yeah this is a recurring topic. But let's see if there are new things to learn/experience to share.

So, what are good file systems these days to consider for a small system? Primary storage would be Flash - either QSPI, or SD cards - and typical code size would be under 50 KB, with RAM size use under 32 KB or so.

How big a "disk" do you want to use?

I don't know what was the best filesystem in the 1977-1981 time period out of Apple DOS, CP/M, FAT, or the UCSD P System (or others). They were all very basic and had low limits on the number of files, the size of an individual file, file name lengths, maximum disk size (without huge clusters) and so forth. Generally they didn't support subdirectories. Many of them didn't record the file length in the directory, so text files needed hacks such as storing a ^Z in the actual file.

Of all of those, FAT may or may not be the best, but it's definitely the only one that is still in widespread use and supported everywhere.

I imagine that you could make a really small but upward compatible version by dropping features such as directories and only supporting FAT12 (ideally under 2 MB, but up to 64 MB with 64 KB clusters) or FAT16 (fine for 2 MB to 2 GB).

No doubt someone already has. For example a FAT16 only library at https://github.com/greiman/Fat16/tree/master/Fat16

But maybe the full-fat FatFS library is fine. I don't know what size it compiles to. Internet sees to think people are using it on AVRs.

As much as I hate FAT in general, it doesn't seem worth investing the time to build or use something that isn't FAT-compatible.

[T3sl4co1l]

FYI, I've given FATFS a spin on AVR and it takes something like 10kB (including support for 64-bit integers because 4GB+ SD cards).
http://www.roland-riegel.de/sd-reader/doc/index.html

I... y'know, I'd say exactly what it is, I have the project here with object files sitting around, but because everything is spammed into a zillion sections other than plain-vanilla .text, .data, .bss etc., size just tells me it's empty. So, unless you have an idea how to calculate totals without linking it(..?), we'll just have to go on my recollection of what it added... which isn't great as I can't remember if it was 10 or 12k, or maybe I was thinking of the project total, or what it is down to the byte. Anyway, total on the link is close to 10k; YMMV with what version of GCC you're using.

Tim

[magic]

Writes should be efficient but also minimally prone to corruption in case of power loss.

Is there a risk of losing a whole page of data if you cut-off power to an SD card during writing?

Because if there is then updating FAT metadata will risk nuking a whole bunch of files, or at least a big chunk of the file being updated, if it's large enough and not fragmented.

edit
That being said, FAT is the default filesystem for SD cards and lots of cameras etc use it everyday with some degree of success. I think I have even heard that the initial sectors that typically hold FAT metadata may be made to be more durable than the bulk of the card, but don't quote me on that.

[brucehoult]

FYI, I've given FATFS a spin on AVR and it takes something like 10kB (including support for 64-bit integers because 4GB+ SD cards).

Yeah, so it says there the FAT16 code uses 7928 bytes of AVR code, and 188 bytes of static data.

That's on top of whatever is needed to physically read and write data to the storage, but that's independent of filesystem. I'd imagine the code would be smaller for ARM or RISC-V.

It says the author is using an AtMega168 with FAT16 but FAT32 needs a 328.

[NorthGuy]

SD and QSPI flash are totally different.

If you use SD, you most likely will have to read/write it on PC, so you typically would use a flavour of FAT which will be compatible with PC or with other devices where you're going to stick your SD in. The choice is not really yours.

If you use QSPI flash, you often don't need any file system at all. Say, for a data logger you may just write fixed-size records circularly. This way you always have your flash filled with the most recent records. Using file system will only add overhead and make everything less reliable.

Other time, you may need a file system in your QSPI flash. E.g. if you want a web server, you may use some sort of home-made read-only file system to fetch the appropriate pages. Or, if you device pretends to be MSD, FAT is a good choice.

There's no one-fit-all solution for using with QSPI flash.

[SiliconWizard]

Yeah this is a recurring topic. But let's see if there are new things to learn/experience to share.

So, what are good file systems these days to consider for a small system? Primary storage would be Flash - either QSPI, or SD cards - and typical code size would be under 50 KB, with RAM size use under 32 KB or so.

How big a "disk" do you want to use?

Up to several GB. I don't want a FS that is restricted to 2 GB, for instance.

But maybe the full-fat FatFS library is fine. I don't know what size it compiles to. Internet sees to think people are using it on AVRs.

For code size, I made a few experiments depending on configuration. Compiled it for x86_64 and also for ARM Cortex-M(7). Interestingly, code size for both targets is pretty similiar.

With the FatFs options I would need, I get ~18 KB (no exFAT support), and ~38 KB with exFAT enabled. That's absolutely not a problem. Compiled with the "read-only" option, this further cuts down size.
(Of course depends on optimization levels. Using '-Os', it's down to 24 KB with exFAT.)

For the record, compiling it with various options using "-Wall -Wextra" yields zero warning, which to me is a good point. Also ran Cppcheck on the code and it yields only a few, very minor warnings.

[SiliconWizard]

Writes should be efficient but also minimally prone to corruption in case of power loss.

Is there a risk of losing a whole page of data if you cut-off power to an SD card during writing?

Yes of course. The term used for SD cards is "blocks" rather than "pages", but it's just a matter of terms. The default block size is 512 on modern SD cards.

A few vendors claim - as some have said above - to have protection against data loss in case of power loss - but I don't know how effective that could be. We could only imagine that for that to work, the card would need to have sufficient capacitance on the power rail to allow completing a block write. I don't know how realistic that is given the size of the cards - in particular for microSD cards. SD cards (not microSD) usually have a whole PCB with bigger passives on it, so that looks already more doable.

Because if there is then updating FAT metadata will risk nuking a whole bunch of files, or at least a big chunk of the file being updated, if it's large enough and not fragmented.

There sure is.

edit
That being said, FAT is the default filesystem for SD cards and lots of cameras etc use it everyday with some degree of success. I think I have even heard that the initial sectors that typically hold FAT metadata may be made to be more durable than the bulk of the card, but don't quote me on that.

As you said, there's a difference between "some degree of success" and "reliable". Cameras and cell phones are big enough that they can embed all the capacitance that would be needed to successfully complete writes, and decent software does the rest. Now if you physically remove the card when it's writing blocks, that's something else.

FAT has been used with "some degree of success" in a very large number of applications, including computers for several decades, but that's definitely not a robust file system. It can corrupt very easily.

SD cards used as a commodity in consumer products is not a good example of reliability. As we pointed out, it's not even possible, apart from a few exceptions, to know if the card's controller does any kind of wear leveling, whereas it's an information you always get (and anyway, they all do) with SSDs.

[brucehoult]

SD and QSPI flash are totally different.

If you use SD, you most likely will have to read/write it on PC, so you typically would use a flavour of FAT which will be compatible with PC or with other devices where you're going to stick your SD in. The choice is not really yours.

That's not really true.

You can always put the SD card into your PC, tell it to ignore (not try to mount) it, and use dd to do a binary copy into a disk file. Then you can read it with probably the same C library you used to write it on the microcontroller.

[NorthGuy]

You can always put the SD card into your PC, tell it to ignore (not try to mount) it, and use dd to do a binary copy into a disk file. Then you can read it with probably the same C library you used to write it on the microcontroller.

Good idea.

[SiliconWizard]

SD and QSPI flash are totally different.

If you use SD, you most likely will have to read/write it on PC, so you typically would use a flavour of FAT which will be compatible with PC or with other devices where you're going to stick your SD in. The choice is not really yours.

That's not really true.

You can always put the SD card into your PC, tell it to ignore (not try to mount) it, and use dd to do a binary copy into a disk file. Then you can read it with probably the same C library you used to write it on the microcontroller.

I didn't first comment this NorthGuy point because it looked like unncessary digression, but you're of course right, here. I even explicitely mentioned that if you needed easy data exchange using SD cards, FAT/exFAT was the way to go, but there are many use cases in which you don't care about that. SD cards still have many benefits over QSPI flash in a range of applications; including an impossible to beat capacity/cost ratio, and the ability to replace them easily. And yes of course, as you mentioned, you can always write your own tools for reading and writing to them on a PC if needed - which is what I mentioned I did in one project. Not being able to easily read from and write to them without using the right tools can even be a plus in some applications.

[Berni]

ElmChans FatFs has always been my goto filesystem library. It is very well tested over the years and supports a pretty good set of features. Lots of the fancy features can be turned off easily with defines to compact it down some more.

But if you want it tiny he has a special Petit FatFs library that is cut down even more and designed to run on 8bit MCUs:
http://elm-chan.org/fsw/ff/00index_p.html

It might be a bit more annoying to use, but it is tiny for sure. Any smaller than that that likely means resorting to a raw format.

SD Cards indeed do not like having there power taken away when writing. It is the most common way SBCs like the raspberry get the filesystem destroyed and fail to boot after a bunch of power cycles. You can get more control in QSPI. The QSPI can also be advantageous for logging applications because you can write to them sequentially without the need to erase flash pages. This gives faster and more predictable write performance and is safer to power loss since only the last written chunk of data might get garbeled.

[cfbsoftware]

You can always put the SD card into your PC, tell it to ignore (not try to mount) it, and use dd to do a binary copy into a disk file. Then you can read it with probably the same C library you used to write it on the microcontroller.

You can also access the SD card as a raw device / physical device directly from your software on Windows in Administrator mode. We wrote a C# module to do this which we then call from Component Pascal using the following tip:

https://www.arsenal-of-wisdom.org/?p=766

You can always put a small dummy FAT partition at the beginning of the SD Card if you want to stop the PC complaining when you insert the card 

[SiliconWizard]

You can always put the SD card into your PC, tell it to ignore (not try to mount) it, and use dd to do a binary copy into a disk file. Then you can read it with probably the same C library you used to write it on the microcontroller.

You can also access the SD card as a raw device / physical device directly from your software on Windows in Administrator mode. We wrote a C# module to do this which we then call from Component Pascal using the following tip:

https://www.arsenal-of-wisdom.org/?p=766

You can always put a small dummy FAT partition at the beginning of the SD Card if you want to stop the PC complaining when you insert the card 

Yes and yes.

[Berni]

Actually that is a pretty good idea because you can use the small FAT partition at the beginning to hold an exe application for reading the data.

You get a readme,txt with instructions along with a exe that upon running checks what drive letter it is running from, checks what physical drive that letter is assigned to then opens that drive for raw access. That exe then gives you a way to browse trough the data and export it into some PC friendly file format like a CSV or something.