The points I meant to make are:
1. embedded systems need to be able to save data that is non-volatile
gathered at run-time.
2. A standard file system is an easy interface to save such data
3. This standard file system needs to have a slightly different behavior
when using flash as a storage medium (fewer writes, compression, etc.)
4. JFFS fits part of these requirements
5. NetBSD doesn't have flash block device support (at least in 1.6) now.
6. Embedded systems sometimes go down "uncleanly" making a more fault
tolerant FS a better option.  JFFS being a "log-based" file system is more
fault tolerant.
7. JFFS would be a good start at supporting flash better in NetBSD.

Kyle


> -----Original Message-----
> From: David Laight [mailto:david@l8s.co.uk]
> Sent: Thursday, February 20, 2003 10:16 AM
> Cc: tech-kern@netbsd.org
> Subject: Re: JFS
> 
> 
> On Thu, Feb 20, 2003 at 11:54:36AM -0500, Thor Lancelot Simon wrote:
> > 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.
> 
> You definitely want to minimise writes to flash, so noatime 
> and nodevmtime
> are a must.  Also all flash memory has quite large physical sectors,
> (they were 128kb on a board I used) so writes have to be large RMW
> cycles - and the erase takes ~1 second (some modern parts may 
> be faster).
> 
> Compact Flash cards aren't the answer either.  I've seen the effects
> (I think) of the power being removed while the card was reorganising
> the sectors.  Certainly I don't think there is anyway the system code
> could have got the flash contents into the absolute mess they were in.
> 
> 	David
> 
> -- 
> David Laight: david@l8s.co.uk
>