On Thu, Mar 15, 2001 at 03:31:50PM -0500, daniele@ncssm.edu wrote:

 > Yes, but not on a NetBSD Flash FS, unless I haven't heard about it, and I
 > think it would have come up already.  I think that FS design is fairly
 > difficult (I have no experience here, mind), and flash particularly so
 > because of the limit on number of writes, and if the work is done and
 > useable, all the better.  If it's not usuable, then I guess it needs to be
 > redone.  No offense intended whatsoever;  I apologize if any was taken.

Did you read my message?  We can't use the Midori *code* for a couple of
reasons:

	(1) It has an incompatible license on it.

	(2) Linux file systems have a COMPLETELY different interface to
	    the rest of the kernel than BSD file systems do.

Point #2 means that we'd have to rewrite a vast majority of the code *anyway*.

I did say that we could study the Midori flash file system, understand how
it works, and then implement the ideas in a file system for NetBSD.  Hey,
and some of us have done file system work before, even (I spent 5 years
working for a distributed supercomputing research center, a fair amount of
the time I spent working on mass storage problems, including file system
issues).

There are other things to consider in a flash file system other than the
limited number of write cycles (and there are pretty obvious techniques
for dealing with that anyway).  The most important one, esp. for embedded
systems, is something called "run-in-place".  Consider the case of a
memory-mapped flash... copying a read-only VTEXT page from the flash to
a RAM page seems pretty wasteful if you can simply map the flash page
directly, eh?

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>