From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Lewin A.R.W. Edwards" To: "Grant Edwards" Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Re: Simple flash filesystem? Date: Tue, 06 Feb 2001 08:21:00 -0000 Message-id: <4.3.2.7.2.20010206111140.00a85360@larwe.com> References: <4.3.2.7.2.20010205171128.00aa9200@larwe.com> <20010206160547.B184E7A814@visi.com> X-SW-Source: 2001-02/msg00071.html 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."