FreeBSD's embedded agenda

[M. Warner Losh]

In message: <1148580598.4475f2f677197 at imp2-g19.free.fr>
            Olivier Gautherot <olivier at gautherot.net> 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.
: 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.

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.

Warner