Jörn Engel posted the sixth version of patches introducing his new LogFS filesystem for flash devices to the Linux kernel. He highlighted some areas of the code that need some more work, and cc'd the appropriate people for further review. Regarding LogFS itself, he noted that one of its big advantages compared to other solutions was improved mount time and reduced memory consumption compared to other solutions, "LogFS has an on-medium tree, fairly similar to Ext2 in structure, so mount times are O(1)." He went on to add that flash is becoming more and more common in standard PC hardware, explaining:

"Flash behaves significantly different to hard disks. In order to use flash, the current standard practice is to add an emulation layer and an old-fashioned hard disk filesystem. As can be expected, this is eating up some of the benefits flash can offer over hard disks. In principle it is possible to achieve better performance with a flash filesystem than with the current emulated approach. In practice our current flash filesystems are not even near that theoretical goal. LogFS in its current state is already closer."

Following the recent announcement that UBIFS is nearly production ready, it was asked how UBIFS compares to LogFS. LogFS author Jörn Engel suggested, "both share similar design goals. Biggest difference is that ubifs works on top of ubi and depends on ubi support, while logfs works on plain mtd (or block devices) and does everything itself. Code size difference is huge. Ubi weighs some 11kloc, ubifs some 30, logfs some 8." He continued:

"Ubi scales linearly, as it does a large scan at init time. It is still reasonably fast, as it reads just a few bytes worth of header per block. Logfs mounts in O(1) but will currently become mindbogglingly slow when the filesystem nears 100% full and write are purely random. Not that any other flash filesystem would perform well under these conditions - it is the known worst case scenario."

Artem Bityutskiy replied, "I personally refuse to compare a finished FS with handles all the crucial flash features to a non-finished FS. It just makes no sense. LogFS was talked about back 2005 in Linux Kongress, but is not finished yet. Let's talk about it when it is production ready."

"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)?"

Jörn Engel announced LogFS, "a scalable flash filesystem." The project's home page notes that LogFS aims to be the successor of JFFS2, "the two main problems of JFFS2 are memory consumption and mount time. Unlike most filesystems, there is no tree structure of any sorts on the medium, so the complete medium needs to be scanned at mount time and a tree structure kept in-memory while the filesystem is mounted. With bigger devices, both mount time and memory consumption increase linearly. JFFS2 has recently gained summary support, which helps reduce mount time by a constant factor. Linear scalability remains. YAFFS also appears to be better by a constant factor, yet still scales linearly."

In contrast, Jörn compared his new LogFS, "LogFS has an on-medium tree, fairly similar to Ext2 in structure, so mount times are O(1). In absolute terms, the OLPC system has mount times of ~3.3s for JFFS2 and ~60ms for LogFS." Regarding its stability, he noted, "LogFS works and survives my testcases. It has fairly good chances of not eating your data during regular operation. There are still two known bugs that will eat data if the filesystem is uncleanly unmounted. Also still missing is wear leveling." Thomas Gleixner reviewed the code and offered the following summary, suggesting the code has a ways to go before it replaces JFFS2, "the code is far from being useful on real world hardware. The error handling via BUG() is just making it useless. Also please fix the coding style and other issues from the seperate review. Some useful comments would make a functional review way easier."