Re: [ECOS] Re: Simple flash filesystem?

["Lewin A.R.W. Edwards" <larwe@larwe.com>]

Hi Grant,

>The filesystem will basically contain web pages and Java applets.

I figured this. So you're dealing with numerous small filelets which will 
mostly be smaller than the block size, and it is not unreasonable to 
reserve at least one block for directory information.

How about this for a solution: Reserve one block (64K) as a directory 
block. Keep that whole block in RAM at all times. Inside it, have a number 
of structures like this:

32bits pointer to file data or NULL if no file exists
32bits file size in bytes
asciiz variable length filename (\0 for non-file)

Keep the directory sorted by file pointer.

When you want to create a new file, you can follow this algorithm:

* if there is a free block (64K), allocate part of it for the file, erase 
that block and write the file to the start of it, and update the directory.
* if there is no completely free block, search for a block that has free 
space in its tail big enough to accommodate your file. Read that block into 
RAM, append your new file into the tail, and erase/writeback the block.

The same algorithm can be used to replace an existing file - simply change 
the existing file's pointer in the directory to indicate that it's no 
longer in use, then follow the steps above.

Depending on how power-failure-tolerant you need this to be, you can get a 
big performance improvement on writes because your directory is all in RAM 
and you only need to commit it back to flash periodically.

This does not perform any explicit wear leveling, obviously, and it also 
doesn't make the most efficient use of space (note the lack of support for 
noncontiguous allocation!). But I think this system might do well for your 
application where you're mostly dealing with tiny files that are not going 
to be rewritten frequently.

>I may just forget about writing individual files and force the user
>to download an entire ROM filesystem everytime anything changes. That
>would be way simpler, but a little slower.

I wanted to do this for one of our products, but I was shouted down 
(legitimately, I think) on the grounds that end-users want to be able to 
read/write randomly. So the project is sitting on the back-burner right now ;)

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."