Date: Thu, 18 May 2006 10:06:09 -0700 From: "marty fouts" <mf.danger@gmail.com> To: "Jim Thompson" <jim@netgate.com> Cc: gnn@freebsd.org, freebsd-small@freebsd.org Subject: Re: Flash File Systems or Translation Layers? Message-ID: <9f7850090605181006m56c38a56lcc7037beaf6b6fa@mail.gmail.com> In-Reply-To: <A2451718-0B8F-4BF2-9466-F6EDC6DC212B@netgate.com> References: <m2bqtwoena.wl%gnn@neville-neil.com> <446BBE65.50104@FreeBSD.org> <9f7850090605171746p5ff4dbefq46211ce93aafc116@mail.gmail.com> <446C2380.6020000@FreeBSD.org> <A2451718-0B8F-4BF2-9466-F6EDC6DC212B@netgate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/18/06, Jim Thompson <jim@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. > 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. > 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9f7850090605181006m56c38a56lcc7037beaf6b6fa>