OSNews

The OLPC XO, OpenMoko, and most other MTD-based Linux systems use JFFS2. The Asus EeePC is an FTL-based device, so it uses an ordinary ext2/3 filesystem.

LogFS does seem to be the future. I haven't checked up on it since last spring, so I don't know how many of the outstanding issues have been addressed, but the design concept is very nice.

Comparing mount times to JFFS2 is like quoting 0-60 times for a golf cart. In exchange for its simple log-structured design, JFFS2 has to process every metadata block in the filesystem at mount time. It was originally intended for small media (several MB), where a couple of seconds to mount the filesystem isn't that big a deal. But when seconds turn into minutes on larger volumes, it's no longer workable.

LogFS is a journaling filesystem. The name was chosen to poke fun at JFFS2 for calling itself a journaling filesystem even though it is log-structured. It uses a more sophisticated metadata structure that allows fast lookups without an in-memory table.

Instead of indexing inodes by offset into the volume, in LogFS they're indexed by offset into a special inode file pointed to by one of two journal blocks that flip-flop on each update. Since data on a Flash medium can only be modified through relocation, decoupling inode numbers from physical geometry makes a whole lot of sense.

To the best of my knowledge, Windows XP has no first-party support for MTD Flash media. Windows can only be installed on the XO if it is equipped with an FTL-based SD card, and even then the onboard MTD will be invisible in Windows. MTDs require a block I/O path and filesystem that are explicitly designed to support Flash.

However, the best filesystem for FTL-based media is FAT32. FTLs treat the OS filesystem as a black box unless they're programmed to understand the particular layout. Many FTL implementations can do aggressive garbage collection with FAT32 by using the metadata to identify free blocks. Since other filesystems are more complex and less common, the FTLs fall back on more conservative algorithms.

Other considerations, such as the ability to avoid fragmentation, are mostly irrelevant since we're dealing with a filesystem mapped onto another filesystem without its knowledge. Any attempt by the OS filesystem to optimize allocation is like trying to find your way around Manhattan with a map of Boston. This is why I consider the Flash FTL to be among the worst computing abstractions in common use today.

Edited 2008-01-25 03:26 UTC