Flash File Systems or Translation Layers?

[Jim Thompson]

On May 18, 2006, at 7:06 AM, marty fouts wrote:

> On 5/18/06, Jim Thompson <jim at netgate.com> wrote:
>>
>> There is at least one 'other' important bootloader for this work:
>> 'redboot'.  (But redboot supports (or can be made to support) jffs2.
>>
>
> The ARM board I'm currently using has redboot on it, so I've done some
> investigation. It looks like ecos/redboot are pretty much dead.

I have no idea how you got that impression, but ecos/redboot are at  
least as "alive" as linux is, and more
popular than u-boot.  (I had my mitts on u-boot back when it was  
"ppcboot".)

>> Still having a bootloader that knows how to 'read' the filesystem
>> isn't that important, as long as you can store the kernel somewhere
>> other than >in< the filesystem.   No "dinking" needed.  (are you
>> aware that 'dink' is also a bootloader (for ppc)?)
>
> Agreed. This seems to be a common approach in shipping devices, and it
> has advantages that make it appealing.

What is "this"?
>
>> We >do< want a FTL or FFS, it doesn't >have< to be JFFS2, but JFFS2
>> has many nice features (on the fly compression, wear-leveling, etc.)
>> so its worth studying, at least.
>
> JFFS2 has a built in design flaw. The 'node' model that it uses
> requires that the entire file system be read during boot. On large
> NAND devices with nearly full file systems, this can lead to long
> delays before the file system is in a state where it can be written
> to.  (I've seen delays of over 20 minutes on actual devices.)
>
> This is why the authors were off designing JFFS3.  Definitely
> investigate JFFS2, especially reading the archives of the MTD mailing
> list, but I'd strongly advise against modeling a system on its data
> structures.

In practice this is only a problem for systems with a >lot< of  
flash.  Most of the boards that are
interesting have 4-16MB of flash.

>
> At PalmSource last year, Mike Chen and myself did an implementation of
> LFS that was NAND-aware for PalmOS Cobalt (the one that never shipped)
> that seemed to have reasonable performance.
>
> For NAND there's also YAFFS2, which is GPLed, and so would need to be
> studied rather than used. (The YAFFS mailing list has a few
> discussions on the limitations of the MTD layer wrt to file systems,
> also.)
>
> I'm aware of several commercial flash file systems for NAND and
> they've all taken the approach of having a block-translation layer
> that handles all of the wear-leveling and block remapping issues.
> Having worked on NAND file systems tof both kinds, I'd particularly
> recommned the separation model.


I don't think we can restrict ourselves to supporting only NAND  
flash.   In particular, Intel's "Strataflash" (and the Micron (etc)  
equivalents are all NOR-based.