On Friday 01 February 2013, Gerald Coley wrote:
One thing I am not sure of is if there are things we can do in the driver to improve things based on the Micron controller. One idea is that as we know the controller and are not subject to heaven only knows what controller is in the SD card a person buys. They are all over the map.
The most important thing to do is to educate users that they need to align their partitions to the 2MB erase block boundary. There are still old manuals that recommend aligning the data partition to logical "cylinder" numbers, which makes the partition completely unaligned to the hardware geometry.
2MB erase block size isn't all that bad. Bigger eMMC chips can have 8MB erase blocks or worse, which is much harder to optimize for.
Using f2fs in Linux-3.8 and later should be a significant improvement over what you can expect with ext4 and btrfs today (I really hope that nobody uses ext3 any more, that would suck a much more on flash devices like this one). An aligned f2fs with 2MB log size should be just fine, although there is some debate over whether you should be using 4 or 6 logs in that case. Using 4 logs is better tuned to the hardware in this case, but 6 logs has better garbage collection in the file system, so answering this question needs some more benchmarking, and it may be workload dependent.
There is a mode that allows better performance, but it has some risks. I don't recall what they are. So if we can make the driver not generic, but specific, then we may be able to squeeze more out. I think it is worth looking into.
There isn't much on the driver level that you can do for a specific flash chip, it's all in the file system. I could ask my contacts at Micron though to see if there is a way to increase the number of concurrent erase blocks on this thing. This would make the boot time a little worse but give you better performance and less wear.
Arnd