Alan Barrett wrote:
> On Sun, 19 Mar 2006, David Young wrote:
>   
>> I am seeking the NetBSD community's requirements and recommendations
>> for a flash filesystem that is suitable for embedded systems.
>>     
>
> I suggest separating the wear-leveling part from the
> survives-power-failure part, in such a way that one could have
> any-file-system on new-wear-leveling-layer on any-block-device; or
> new-file-system on any-block-device.
>
> --apb (Alan Barrett)
>   

Weal-leveling necessarily needs to know something about the block layout
of the device.  I think it is also the case that a lot of
"wear-leveling" strategies that you might employ depend on knowledge of
the file system.  (E.g. a log structured file system like jffs2 pretty
much does wear-leveling on its own.)

Trying to separate this out sounds "nice", but I don't think it really
adds much value (i.e. why are you going to want to run e.g. ffs on
flash?  It would be silly, given the way ffs works.)  For a significant
number of systems, a much bigger benefit would be to have compatibility
with the flash file system already in use.  (So that e.g. bootloaders
and multi-boot systems can be used.)

Also, current filesystems (like ffs) want a uniform block size, which
not all flash parts use.  (Some devices differ both in the "normal" size
of blocks, and in the fact that not all blocks, or sectors in flash
parlance, on a given part are the same size.)

I hear of problems with JFFS2, but they mostly sound like complaints in
the Linux implementation, and not intrinsic faults of the on-device
storage format.  The exception to this being that JFFS2 might be
suboptimal for very large flash devices (e.g. 1GB NAND).  Fixing *that*
issue would most likely require a redesign, and is, IMO, a less critical
need than we have right now, which is to get something that is
"basically usable" for existing embedded devices with much smaller (<
256M) flash parts.  For these embedded systems, I consider compatibility
with boot loaders more important than future upward scalability.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191