Samsung's F2FS filesystem
Posted Oct 10, 2012 14:49 UTC (Wed) by dwmw2
In reply to: Samsung's F2FS filesystem
Parent article: Samsung's F2FS filesystem
"What we've heard is:
1. Raw NAND changes a lot requiring near constant requalifying of parts as vendors change their manufacturing processes.
There's a certain amount of that, but not nearly as much as with eMMC devices. As I mentioned elsewhere, those have been known to change the whole
of their internals — both the FTL implementation and all of the hardware, microcontroller and all — without even changing the model number. It's just completely a different device, with completely different performance and reliability characteristics, from one batch to the next. But because it's still a black box which pretends to be a 16GiB 'disk', they don't see the need to change the model number.
At least with NAND devices, the issue is mostly just that your board manufacturer finds alternative suppliers for the "same" device so you need to requalify timings, etc. Unless you have a particularly recalcitrant ODM, you should at least get some notice of that kind of thing rather than finding it out post-build-run.
I know there are some people claiming that NAND technology changes too fast, and it's impossible for software to keep up. I'm not sure if that's what you're referring to above, but I'll bring it up so that I can point out that it isn't really true; the people who say this are not speaking from a position of experience. Erase block and page sizes have grown over the years, and the number of writes you can make to a given page has decreased from about 10 writes to a 512-byte page in the 1990s, to a single write (or less than that with paired pages) now. And you need stronger ECC as the underlying technology gets less reliable (especially with MLC). But fundamentally, it's fairly much the same. NAND support was retrofitted to JFFS2 after it had been designed to work with only NOR flash, and the same NAND support is just as valid on today's flash as it was then.
"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."
Most decent SoCs have hardware ECC support on the NAND controller so that shouldn't suck CPU time. And with DMA support, even garbage collection shouldn't take time. If you have specific examples of UBIFS taking "considerable processing power"
it'd be interesting to analyse them and see where it's being spent. Note that it'll be garbage collection, not wear levelling per se, which takes the time. Wear levelling is mostly just a matter of choosing which victim blocks to garbage collect from; in itself it isn't time-consuming. Occasionally it means you choose a completely clean
block as a victim, and move its entire contents to another physical block. But that should be rare.
to post comments)