Re: FreeBSD's embedded agenda

On May 25, 2006, at 10:10 AM, M. Warner Losh wrote:

> 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.

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.