On Thu, Feb 20, 2003 at 07:48:31AM -0700, kyle.unice@L-3com.com wrote:
> Also NetBSD is weak on its flash support.  Embedded systems need file
> systems that can tolerate being power off without warning and to have a file
> system supporting compression.

I build routers that run from flash for a living, and I strongly disagree
with your conclusion, for several reasons:

1) If you want resilience when the machine's suddenly powered off, use
   fsync() appropriately to get the commit semantics you require, or
   simply mount the filesystem read-only.  It's trivial to do (in most
   cases, one will want to do both of these: read-only for the system
   image and a tiny read-write partition for the data).  FFS "tolerates 
   being power off without warning" just fine and you can mount it "sync"
   if you aren't sure you can manage to use fsync() correctly.

2) It's trivial to compress the filesystem of an embedded NetBSD system.
   You can:

   A) gzexe all the executables.
   B) lift the code from one of the other BSDs to do the same thing in the
      kernel
   C) Run from a filesystem that came from a compressed RAM disk, just as
      the install media do.

RAM is cheap, though flash is pricy.  Option C) eats some RAM, but saves
some flash.  In the Linux world, there's a filesystem that does per-block
compression ("cramfs") but it's so buggy it's basically unusable and
everyone just uses read-only ext2; similarly, there's a "journaling flash
filesystem" that tries to do block-shuffling, but again, it is so buggy
that nobody ever mounts it read-write except briefly to replace the system
image (so they _might as well_ just use ext2, but, you know, then they
wouldn't get to feel good about themselves for using the JoUrNaLiNg FlAsH
FiLeSyStEM... sigh).

Thor