Re: Flash disks and FFS layout heuristics

On Sun, Mar 30, 2008, Matthew Dillon wrote:
The idea of remapping flash sectors could be considered a poor-man's
way of dealing with wear issues in that remapping tends to be fairly
limited... for example, you might use a fixed-sized table and once the
table fills up the device is toast. Remapping doesn't actually prevent
the uneven wear from occuring, it just gives you a fixed factor of
additional runway.
[...]
A flash unit must therefore run a scrubber to really be reliable. It is
absolutely required if you use a remapping algorithm, and a bit less so
if you use a proper storage layer which generates even wear.

Yes, this is essentially what modern NAND flash devices do. I
suggest that you read this article before you write any more
essays about it:

http://www.cs.tau.ac.il/~stoledo/Pubs/flash-survey.pdf

Now if you think about issues such as sector mapping updates,
writes smaller than the mapping granularity, and running the
cleaner on fragmented erase units, you'll quickly see why random
writes perform so poorly.

You're right that you need additional algorithms to avoid uneven
wear; remapping merely facilitates that even when the write access
pattern is decidedly uneven. The article discusses several approaches.

Several people have proposed flash-aware filesystems, also
described in the article, to obviate the need for this sort of
remapping layer. Confusingly, one of them is called FFS, for
"Flash File System". Most of them resemble log-structured
filesystems like LFS and ZFS, but often with additional
considerations such as wear leveling.

Your earlier characterization of ZFS wasn't quite right, by the
way; ZFS arranges data and metadata in a tree of blocks, and even
the indirect blocks, except for the top-level block, are
copy-on-write. Unfortunately I can't find a good paper on it at
the moment.
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"