> 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.
