Re: FreeBSD's embedded agenda
Jim Thompson <[email protected]> Thu, 25 May 2006 16:50:49 -1000
| Newsgroups | gmane.os.freebsd.devel.small |
|---|---|
| Message-ID | <[email protected]> |
On May 25, 2006, at 10:10 AM, M. Warner Losh wrote: > In message: <[email protected]> > Olivier Gautherot <[email protected]> writes: > : Hi Andrew! > : > : > [...] > : > > The reason Flash Adaptation Layers came about in the first place > : > > is that W95 didn't support anything but FAT. > : > > : > > : > Hmm. I was thinking about partitioning the problem actually. > Make flash > : > look like a disk and then you can put any filesystem on it that > you > : > want. Seems a heck of a lot simpler .. and I'm not sure if I > see any > : > drawbacks to doing it that way ... > : > : The drawback is the following: what would happen if you had an > application > : opening-writing-closing a file in /var/log on a regular basis? > The block > : would decay with time, with chances that your log even gets > corrupted. its much worse than you present. superblocks, directory inodes for /var/log, inodes (never mind the blocks for the file) for /var/log/foo (mod/access time updates), etc. > : That's why Flash drivers have to spread write accesses across the > device > : (what FFS doesn't naturally do). Also, there is a constraint > regarding > : the changes allowed: on NAND flash, you can write a 0 on a bit > but have > : to erase the full block to write a 1 back. > : > : Don't forget that Flash doesn't suffer from mechanical delays so > there > : is no harm in fragmenting the filesystem: this would be another > feature. though erasing a sector (for NAND flash) is a relatively slow operation. > There's at least one implementation of a geom_nand layer that tries to > wear average blocks from a pool it keeps. However, it would be far > better if it could get hints from the file system layer when blocks > were freed. Once you get to that level of abstraction, you might as > well just do all the work yourself. It gets kinda hairy to do it > generically for any filesystem. One problem with allowing excess fragmentation is that you might not be able to find a larger contiguous set of sectors, if your file/filesystem geometry requires same. This is why JFFS2 does GC. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-small To unsubscribe, send any mail to "[email protected]"