From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Grant Edwards" To: "Lewin A.R.W. Edwards" Cc: ecos-discuss@sources.redhat.com Subject: [ECOS] Re: Simple flash filesystem? Date: Tue, 06 Feb 2001 08:05:00 -0000 Message-id: <20010206160547.B184E7A814@visi.com> References: <4.3.2.7.2.20010205171128.00aa9200@larwe.com> X-SW-Source: 2001-02/msg00070.html Lewin A.R.W. Edwards writes: > >I've been looking for info on flash filesystems, and have found pretty > >much nothing. > > Random notes: > > I suspect that the reason you haven't found many references is that > these sorts of applications (in my experience so far) fall into these > categories: > > 1. Cases where you _want_ to emulate a DOS-type filesystem, especially > cases where you have an underlying flash controller that does the > level-wearing and error correction for you, and In my case, I've got no reason to want to emulate a DOS filesystem. > 2. Cases where you're only going to write data once in a blue moon, and > it's most efficient to solve the problem on an ad hoc basis. That's pretty much my situation. The filesystem will be use to hold read-only stuff that's only changed infrequently, and the system doesn't have to operate "normally" during the update process. The filesystem will basically contain web pages and Java applets. Once the user has got the web pages working they way he wants, the filesystem will be strictly read-only for normal operation. 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. > The main performance hit I encountered in emulating a DOS filesystem over > dumb flash is updating the FAT. If you can keep the whole FAT, or at least > all the sectors for open-for-writing chains, in RAM (and only update > sections when open-for-write files are closed), you'll have a huge > performance increase. Since writes are going to be rare, and the system is allowed to be "down" while they happen, even a DOS filesystem is probably overkill. > To find a particular file you start at the beginning of filespace and get > the first word (pointer to next file). You then check the filename > immediately after the word. If it's the file you want, then read it out. If > it's not the desired file, then use the pointer to skip to the next file > until you find the one you want or reach the end of the chain. That's similar to the ROM filesystem currently used by the GoAhead web server. If I stick with that, I'll just download the entire filesystem every time. What I'm trying to figure out is what the simplest solution would be that would allow downloading individual files. I was surprised that I couldn't find much using google/deja. > Maybe you might want to consider NAND flash (SmartMedia in a chip package, > essentially) for your file storage. It does have the benefit of having a > block size that is exactly the same as the best DOS cluster size for the > media capacity. And it's fairly easy to work with. I'm pretty much stuck with "regular" flash (64k sectors). -- Grant Edwards grante@visi.com