Date: Thu, 25 May 2006 16:08:57 -0700 From: "marty fouts" <mf.danger@gmail.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Paul Allen <nospam@ugcs.caltech.edu>, current@freebsd.org, Olivier Gautherot <olivier@gautherot.net> Subject: Re: FreeBSD's embedded agenda Message-ID: <9f7850090605251608p27c71475wa6d245f8a5f1185f@mail.gmail.com> In-Reply-To: <5583.1148593117@critter.freebsd.dk> References: <20060525210132.GD28128@groat.ugcs.caltech.edu> <5583.1148593117@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/25/06, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > I wish I could be more specific to guide you and others onto the > right track here, but for now I will have to reiterate: Tailor > the filesystem to flash devices, there are so many benefits to > be had that way. I'd go a step further. I advocate treating NOR and NAND devices seperately. There are enough difference in their behavior to justify optimizing implementations for each. Compare JFFS2 to YAFFS2 on NAND and you'll get an example of how this can happen. I would advocate a split-but-aware approach. A flash translation layer, which manages bad blocks, wear leveling, and even garbage collection, is a good logical separate entity, provided it exposes hooks to the file system to allow the FS to teach it about dead blocks. Couple this with a well designed journaling FS, and you get an FS that overcomes the uglier properties of flash, especially of large block size NAND, but that can live above layers that are optimized for NOR, NAND, or the coming hybrid flash models. (You can easily argue about where the garbage collection belongs. I've done it both ways.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9f7850090605251608p27c71475wa6d245f8a5f1185f>