Linked by Thom Holwerda on Thu 24th Jan 2008 21:20 UTC, submitted by anonymous
Flash filesystem specialist Datalight Inc. will soon release a commercial Linux FFS claimed to provide 400 percent the write performance and 500 percent the mount speed of JFFS2. The company's new commercial FFS will target Linux-based mobile phones, set-top boxes, and other embedded devices.
Thread beginning with comment 297707
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Everybody knows JFFS2 is not perfect
by lemur2 on Fri 25th Jan 2008 04:06
in reply to "RE[2]: Everybody knows JFFS2 is not perfect"
Member since:2007-02-17
Other considerations, such as the ability to avoid fragmentation
You surely don't need to avoid fragmentation on a random-access device. What does it matter where the next block is located on the media when the access time to the next block is the same no matter where the current block is located?
However, the best filesystem for FTL-based media is FAT32.
Oh dear, FAT32. The filesystem (AFAIK) that has no concept of file owner, nor of execute permissions, coupled with Windows, the OS that says by default "sure thing, whoever you are asking me to do so, I will execute that uncredentialled file, which I know nothing about other than the fact that the filename ends with '.exe', right away ... ". Windows XP installed using a FAT filesystem is going to be easily compromised in any malware attack.
RE[4]: Everybody knows JFFS2 is not perfect
by Cloudy on Sat 26th Jan 2008 04:27
in reply to "RE[3]: Everybody knows JFFS2 is not perfect"
Member since:2006-02-15
You surely don't need to avoid fragmentation on a random-access device. What does it matter where the next block is located on the media when the access time to the next block is the same no matter where the current block is located?
Not all flash is truly random access. NAND flash, in particular, has peculiar rules about rewriting data blocks once they've been written that makes approaches that minimize metadata writing and fragmentation very important for performance and efficiency.
Member since:
2005-07-08
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