A broken de-facto standard in the area of embedded computing is the use of the File Allocation Table Filesystem (fatfs) for embedded devices with flash chips.
The use of this standard falsely assumes the common notion to be true which claims that fatfs was the perfect file system for embedded devices, due to its simplicity. However, this assumption is not true. In fact, writing to a fatfs requires the same blocks to be written over and over again. Now, a flash only has a limited number of write cycles, meaning that the same sector (unit of usually 1kB) can only be written a certain number of times. For example, usual flash chips only have 10'000 to 50'000 write cycles.
This means that on a plain flash, the FAT file system will cause a write cycle exhaustion after only 10'000 file modifications, due to the fact that one of the rather important blocks containing the file to cluster mappings will be written to every time a file is modified. This means that you can throw away your flash device.
Modern file systems for embedded devices circumvent this by their very structure. The 4.4BSD log structured file system (LFS) for example doesn't ever write to the same blocks again unless it has passed and written to the entire flash at least once. Even if you make modifications to a file, LFS appends the file with a new version to the end of your current file system. At some point, LFS arrives at the end of the flash, which makes it wrap over to 0 and look for a freed block there. At this point, it will for example overwrite old versions of files. In addition to saving rewrite cycles, this even makes write access to the flash a lot faster.
However, flash producers have also found a solution to the fatfs problem. Current flashes carry additional per-block counters which take notes of how many times a certain flash cell has been written to. They also feature a block map which is used to remap flash blocks to other places, allowing blocks that have been written to more often than others to be remapped to less frequently used blocks. This is additional logic which makes the flash itself horribly complicated and expensive, but artificially saves write cycles when used with the fatfs.
An additional problem when it comes to fatfs and embedded devices is licensing. Microsoft has sued an enormous amount of producers of embedded devices in the past over infringement of patents on the fatfs. Under these circumstances, one really has to wonder why so many companies still sell fatfs based devices.
So where does the notion of fatfs as the ideal file system for embedded devices come from? You guess it: Microsoft's marketing department. And the claim is simple: fatfs is easy to implement (Well, LFS is even easier, but you can see where Marketing wants you to go). The easiness of implementation is thereby padded up with the fact that Windows comes with no implementation of any file systems other than fatfs and ntfs. And since ntfs is horribly complicated and its file system driver is probably already larger than most flash devices, fatfs is the only solution with workable interoperability with the Windows operating system out of the box. So if your embedded operating system runs on fatfs, you can just take out the SD card, plug it into your laptop's SD card reader, and use it under Windows.
This is another example of how Windows penetrated the world of standards, while it is only making life harder for the manufacturers. So if you ever want to make an embedded device, it is recommendable to refrain from using the de-facto standard fatfs.