Date: Thu, 18 May 2006 07:50:56 -1000 From: Jim Thompson <jim@netgate.com> To: "marty fouts" <mf.danger@gmail.com> Cc: gnn@freebsd.org, freebsd-small@freebsd.org Subject: Re: Flash File Systems or Translation Layers? Message-ID: <2159F853-C89E-4032-9931-56F4B7D214C0@netgate.com> In-Reply-To: <9f7850090605181006m56c38a56lcc7037beaf6b6fa@mail.gmail.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> <9f7850090605181006m56c38a56lcc7037beaf6b6fa@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 18, 2006, at 7:06 AM, marty fouts wrote: > 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2159F853-C89E-4032-9931-56F4B7D214C0>