Last post here on this, because there might be a few interested bods out
there. [Any more and we'll go off-list... promise!]
> I have been trying to familiarise myself better with
YAFFS (I have at times
> pondered about contacting you privately), but I must volunteer I
haven't
> quite got the full grasp on it yet that I would like :-)
Send me an email address and I'll send you a 20 page doc :-).
> I've been writing my own FFS as well, for a
specific app and suitable to
> eg. SAM7, MSP430 et al (IOW no OOB space is needed), but I'm still
storing
> my VBM in RAM. My next step is to clean up usage of VBM in Flash.
If you're using a very small micro (which many of the SAMs are), then a
full
POSIX file system like YAFFS is big-time overkill and won't run in the
resources of many smaller micros.
Often a very simple "linear file store" type file system is far more
appropriate. It is generally the more curveball operations that make a file
system complex (eg. handling file "holes" etc). Simple tasks like saving
small config/log files etc are often very much simpler.
Although I have not been activer there for a while, I know the Lejos NXJ
project (alternate firnmware for Lego Mindstormns NXT) has a simple file
system in it and this runs on a SAM using minimal resources.
> ** Out of curiosity, do you use Out of band data in
your FFS ? I found this
> an interesting challenge since eg. microcontrollers with say 512 byte
> sectors can't 'present' 512 byte virtual sectors at the top
layer of the
> FFS, or at least not without losing big amounts of the flash to control
> pages. (I use smaller transfer units eg. 64 & 128 bytes, my app tolerates
> this)
You don't need spare area for YAFFS any more. There are various ways of
working without spare.
>
> I hope this makes more sense - I was trying to avoid to get too technical
> about it :-)
>
> Best regards,
> Kris
>
> -----Original Message-----
> From: A... [mailto:A...] On Behalf Of
> Charles Manning Sent: Wednesday, 2 July 2008 1:25 PM
> To: A...
> Subject: Re: [AT91SAM] FAT file system??
>
> On Wednesday 02 July 2008 15:14:08 microbit wrote:
> > I would second that as well.
> >
> > At one stage I played with EFSL, which had an interesting (but
> > dysfunctional) caching system. There you have to be extra careful, as the
> > 'cache' doesn't fully flush, even when you close a file.
> > FatFs has an f_sync() function that flushes the R/W buffer (when dirty)
> > at any time you wish. While this is less efficient, it's a good
> > precaution for logging apps et al. Increased flushing isn't an issue
in
> > these apps anyway. This is covered on ELM's URL.
>
> I agree with all that.
>
> > If data integrity is important then a Flash Translation Layer is a good
> > idea, as that will resolve these issues, even with FAT.
>
> I disagree.
>
> A robust FTL can protect against various corruptions at the media level,
> but it cannot protect against FAT breaking. Even top-shelf FTLs like
> DiskOnChip can't do that.
>
> For full robustness you need a proper Flash File System (FFS) or some
> journalling/high reliability file system with an FTL.
>
> I hope I did not come across as rude. That was not my intention. This is
> just one of my hobby horses since I wrote YAFFS (a log structured FFS) and
> another fully robust FFS.
>
> Charles
