This new FS is interesting to me because I work for a company that is currently developing a new product line that will be based on DDR3 & some kind of NAND flash. Historically, our products have always been NOR flash and battery backed SRAM or SDRAM using an RTOS. But we recognize how limiting this is and how liberating it will be to function in a Linux environment. But this whole paradigm is new to us and everything we've researched about raw NAND is, well, scarey making eMMC very compelling. What we've heard is:
1. Raw NAND changes a lot requiring near constant requalifying of parts as vendors change their manufacturing processes
2. Raw NAND required both hardware ECC correction in your microcontroller (not a problem for the ARM Cortex based TI AM335x we plan to use), but also requires a FS to handle the wear leveling. While UBIFS and others are probably decent at that, the act of doing that in software has been shown to take up considerable processing power on the processor we've selected.
In contrast, eMMC abstracts many details away from us and our processor so we don't have to deal quite so directly with them nor take the performance hit. But we aren't so naive to believe that the issues are gone. We are still in the very early stages of R&D on this project, so we have the opportunity to architect our firmware in a way that works best with the eMMC. What we don't have a solid handle on is what exactly that will require of us.
We have identified we have both data that doesn't change often (Uboot, Linux Kernel, most of the File system), but then there's other aspects to what we do that will write data far more than it'll be written for the purposes of trend logging. This would suggest breaking the eMMC into 2 partitions, one dedicated to the stuff that doesn't change often, and the other with LOTS of free space and configured for high durability (pseudo-SLC mode). But this is relatively high level. We'd like to know more about the best practices AND worst practices when working with eMMC in an embedded Linux environment.
TI's Arago Linux is up to 3.2.x and will likely be 3.4.x by the time we actually deploy the product to market, so getting things like TRIM, I would assume are a given. Is that a bad assumption? If so, we will need to look into reconfiguring the kernel build to include it if TRIM is a commonly excluded feature in embedded Linux kernel builds.
But more to the point of this thread, the fact that this new FS from Samsung was designed by makers of eMMC to be "flash friendly" is inviting. But before we jump on a band-wagon, I, like others on this site, would like more details on exactly what this new FS does differently from others (i.e. ext4) to improve the performance and reduce write amplification of random-write accesses to eMMC including what "tunable" parameters are there available to us? And how would we know when we would need to tinker with them?