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.
LogFS is the linux filesystem that will reemplace it (in fact it’s near of being included in the main tree, so its not that it’s a alpha project or anything): http://lwn.net/Articles/234441/
What filesystem(s) do(es) new FFS-based Linux systems coming on to the market recently (such as the OPLC XO and the ASUS EEEPC) use currently, do you know?
If they currently use FFS2, there could be an opportunity here by using LogFS instead to dramatically increase the speed of the ASUS EEEPC and similar machines.
BTW: the lwn article you linked to says this:
These seem like excellent reasons not to install Windows XP (and with it NTFS) on to FFS-based systems such as the ASUS EEEPC and the OPLC XO.
Edited 2008-01-25 01:44 UTC
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
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?
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.
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.
Are they kidding? FFS? That’s the name used by BSD for Berkeley’s Fast File System.
Talk about a bunch of idiots… couldn’t they be a bit more creative?
Err.. you said it yourself, it is not so. The file systems have different names which may result is identical abbreviations, if abbreviating is your thing. The names couldn’t be further appart. I can think of a million names that result in identical abbreviations and rightly so, nobody takes offence with that.
Thom, did you not catch the error in their writeup?
“Flash filesystem (FFS) 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.” (emphasis mine)
This is supposed to be supported by later reporting:
“Datalight claims that in early tests of its new Linux FFS it has measured mount times of 0.44 seconds on a 56 MB NAND flash chip, compared to 2.32 seconds for JFFS2 and 0.69 seconds for YAFFS2. ”
But ‘500 percent’ of something is 5x something, which means that the new Linux FFS should be 11.6 seconds. It should in fact say that it is 500% faster.
He said 500 percent the mount speed not the mount time. So, there’s nothing wrong on what he said.
site:www.datalight.com gpl
Reliance for Linux has been around for over a year.
It’s not a new file system, it’s a new release.