"Here is a new flash file system developed by Nokia engineers with help from the University of Szeged. The new file-system is called UBIFS, which stands for UBI file system. UBI is the wear-leveling/ bad-block handling/volume management layer which is already in mainline (see drivers/mtd/ubi)," began Artem Bityutskiy. He explained that UBIFS is stable and "very close to being production ready", aiming to offer improved performance and scalability compared to JFFS2 by implementing write-back caching, and storing a file-system index rather than rebuilding it each time the media is mounted. The write-back cache implementation claims to offer around a 100 time improvement in write performance over JFFS2. Artem went on to note:

"UBIFS works on top of UBI, not on top of bare flash devices. It delegates crucial things like garbage-collection and bad eraseblock handling to UBI. One important thing to note is MLC NAND flashes which tend to have very small eraseblock lifetime - just few thousand erase-cycles (some have even about 3000 or less). This makes JFFS2 random wear-leveling algorithm to be not good enough. In opposite, UBI provides good wear-leveling based on saved erase-counters."

UBIFS is described as, "a new flash file system which is designed to work on top of UBI." It has replaced the JFFS3 project, a choice explained on the project webpage, "we have realized that creating a scalable flash file system on top of bare flash is a difficult task, just because the flash media is so problematic (wear-leveling, bad eraseblocks). We have tried this way, and it turned out to be that we solved media problems, instead of concentrating on file system issues. So we decided to split one big and complex tasks into 2 sub-tasks: UBI solves the media problems, like bad eraseblocks and wear-leveling, and UBIFS implements the file system on top. And now finally, we may concentrate on file-system issues: implementing write-back caching, multi-headed journal, garbage collector, indexing information management and so on. There are a lot of FS problems to solve - orphaned files, deletions, recoverability after unclean reboots and so on."

In a recent posting to the lkml, Artem Bityutskiy noted that UBIFS has to take into account that there is a small amount of unused block space at the ends of eraseblocks, and the size of pages written to disk are smaller than they are in memory as the filesystem performs compression. "So, if our current liability is X, we do not know exactly how much flash space (Y) it will take. All we can do is to introduce some pessimistic, worst-case function Y = F(X). This pessimistic function assumes that pages won't be compressible, and it assumes worst-case wastage." The calculation is necessary as even though data is not written immdiately to the flash device, it's important to be able to inform the application writing data if there's not enough space left. "So my question is: how can we flush _few_ oldest dirty pages/inodes while we are inside UBIFS (e.g., in ->prepare_write(), ->mkdir(), ->link(), etc)?"