There is a very limited set of things that a controller can do with a few KB of RAM. There are two classes that I've encountered:
1. A device that remaps physical erase blocks to virtual erase blocks of the same size and can write into a limited number of them. This covers 99% of the SD cards and USB sticks, as well as the majority of the existing eMMC devices. f2fs should work great (i.e. much better than any other fs we have available) on these devices, as long as the number of open erase blocks in the fs (at most 6) does not exceed the number of blocks the device can handle (vendor specific, somewhere between 1 and 20 normally) and the erase block size is known.
2. Upcoming devices that have a very simplistic log-structured file system on them. This covers one SD card I've seen (Samsung 32 GB Class 10) as well as the majority of new eMMC devices. These will work somewhat better with existing file systems for many workloads but worse in the worse-case workloads. If f2fs uses the eMMC-4.5 "large unit contexts", they will work as good or better as the first class, because that should reliably prevent getting into the slow-path that we see normally when a log-structured device gets into GC.
I can't think of a workload or hardware in which f2fs would not theoretically outperform ext3 or most other file systems we have.
Posted Oct 10, 2012 13:59 UTC (Wed) by jpfrancois (subscriber, #65948)
[Link]
In your classification, does class 1 devices provide ant kind of wear leveling ? If yes how ? By renumbering the virtual mapping ?
Samsung's F2FS filesystem
Posted Oct 10, 2012 19:01 UTC (Wed) by arnd (subscriber, #8866)
[Link]
Of course, they all do wear leveling. This type just picks a new physical erase block every time the user starts writing to a logical erase block that is not currently open for writing. Some devices combine this with 'static' wear leveling, which also occasionally moves data from one erase block to another so that (old) physical block can be put back into rotation.