David Brown wrote:
Georg Ritter wrote:
...
do you write FAT filesystem or a custom format and is your code open
source?
At present there is no filesystem, it just writes 512 byte blocks, but
it skips the first one. If I need a fs, I I'll probably use romfs,
found
on linux.
Hi,
I heard some rumours that M$ is going to change their attitude to the
usage
of FAT. It seems they want to turn down everything/everyone that does
not
pay for a licence in future.
I was loooking into the MMC part too, and therefore was looking for a
suitable
fs. It should be free and easier to write. But it should also be
somehow read/write-able by various OSes. Did really find anything yet.
Greetzs,
Georg
Be aware that FAT is an extremely poor format for MMC if you plan to do
much writing. Compact flash cards have automagic wear leveling
algorithms that prevent premature wearing of sectors. MMC has no such
facility. Premature failure areas are where a directory is stored and
the FAT table itself. If you create a single file, and plan to extend
it to 32MB, and we assume 4K clusters, you'll rewrite the FAT table a
minimum of 256 times, plus additional few times if you create a
subdirectory for where your file exists, etc. This quickly adds up if
you're doing things like collecting vehicle performance data and
offloading it every day. After 40 days, you've done over 10,000 writes.
And if I recall correctly, unlike compact flash cards, MMC cards don't
report write errors, so the only way you'll know you've failed to do a
read verify after each write. Which just cut your performance in half,
and likely required that you have space for a second 512 byte (so as not
to wipe out the original data you're writing).
FAT works great (for small and fully qualified values of great) for R/O
file systems. It's certainly easier to manage than ext2, reiser, or any
other number of systems. And it can be written and read easily by any
MMC equipped PC. But for devices that have finite lifetimes, such as
flash and EEPROM, it's a poor choice, unless you implement the wear
leveling algorithms yourself.
It's along these same lines while you'll read that you should never use
a compact flash card or MMC for /tmp on a Linux system ("Why would
you?", you might think. Think embedded systems).
What about jffs2 ? It is specifically designed for flash systems, and
handles wear levelling and journaling. It also supports compression, which
might be a bit difficult on a small system (since that generally means lots
of ram), but maybe it can be used without compression.
I can't say that I know. I use ext2 in our embedded linux product, and
we don't use swap (and I misspoke before. I meant to say swap, not
/tmp, although /tmp can be a potential source of problems, depending on
the work load). Other systems I've done have been R/O FAT16/32, or in
the case of the MMC, I just preinited the entire card to a known
pattern, and then wrote our data from the start. On the PC side, when
reading, since I knew the length of the block, as soon as I encountered
the formatted pattern, I knew I had hit the end of the data (there was
no file structure, in this case).
The biggest problem with many of the schemes is they are designed on
systems that have more memory than a MSP430 or an AVR. When you need to
store 512 byte sectors, and have 2K or 4K of RAM, one buffer represents
a significant portion of your RAM. When you have 16K, this obviously
drops substantially, and if you've got 64K, you're in hig heaven. Not
to say that I know a lot about the various file system alternatives out
there, but most weren't designed for extremely small footprint systems.
And the few that might exist probably haven't been adopted into Linux or
Windows filesystem support.
This is something I should go and revisit. It's been several years
since I've done a thorough audit of various file systems alternatives.
My requirements would be it needs to be supported under Linux, or easily
implementable as a Linux device driver, and Windows support would be
nice (I'd also like to implement a Linux CP/M filesystem driver, that's
on the List Of Things To Optionally Do One Day In The Future --
LOT.TODO.DITF)
If you did a really comprehensive comparison with real numbers, you
could easily write an article for OSnews.com, linuxdevices.com or the
Embedded Systems Journal. Got some spare time?
--jc
