OSNews: http://www.osnews.com/story/19208/New_Linux_Flash_Filesystem_Offers_4x_Speed Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Tue, 10 Nov 2009 11:45:00 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Everybody knows JFFS2 is not perfect http://osnews.com/thread?297643 http://osnews.com/thread?297643 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/ Thu, 24 Jan 2008 22:10:00 GMT donotreply@osnews.com (diegocg) Comments Linux FFS? http://osnews.com/thread?297648 http://osnews.com/thread?297648 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? Thu, 24 Jan 2008 22:22:00 GMT donotreply@osnews.com (BSDfan) Comments Bad Thom, copying it straight http://osnews.com/thread?297649 http://osnews.com/thread?297649 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. Thu, 24 Jan 2008 22:22:00 GMT donotreply@osnews.com (jdrake) Comments GPL?` http://osnews.com/thread?297651 http://osnews.com/thread?297651 site:www.datalight.com gpl Thu, 24 Jan 2008 22:24:00 GMT donotreply@osnews.com (ernstp) Comments RE: Bad Thom, copying it straight http://osnews.com/thread?297686 http://osnews.com/thread?297686
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. Fri, 25 Jan 2008 00:42:00 GMT donotreply@osnews.com (goedson) Comments RE: Everybody knows JFFS2 is not perfect http://osnews.com/thread?297696 http://osnews.com/thread?297696
LogFS is the linux filesystem that will replace 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:
"Flash is not without its drawbacks. Its relatively high cost limits its applications and it brings its own set of quirks which must be understood and addressed by filesystem developers. Even so, some special-purpose laptops rely on flash for their persistent storage needs now, and there are rumors of more flash-based systems in the near future.

The most significant of the "quirks" mentioned above are:

- Flash storage cannot be simply overwritten like magnetic storage; instead, a flash block must be explicitly erased and rewritten in two separate steps. The size of the "erase blocks" may not match the block size as understood by the operating system; often, the erase blocks are relatively large.

- There are limits to the number of times a block of flash memory can be erased and rewritten before it loses the ability to reliably store data. That limit is generally around 100,000 cycles."


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 Fri, 25 Jan 2008 01:43:00 GMT donotreply@osnews.com (lemur2) Comments RE[2]: Everybody knows JFFS2 is not perfect http://osnews.com/thread?297707 http://osnews.com/thread?297707 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 Fri, 25 Jan 2008 03:21:00 GMT donotreply@osnews.com (butters) Comments RE[3]: Everybody knows JFFS2 is not perfect http://osnews.com/thread?297720 http://osnews.com/thread?297720
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. Fri, 25 Jan 2008 04:06:00 GMT donotreply@osnews.com (lemur2) Comments not new http://osnews.com/thread?297919 http://osnews.com/thread?297919 Reliance for Linux has been around for over a year.

It's not a new file system, it's a new release. Sat, 26 Jan 2008 04:17:00 GMT donotreply@osnews.com (Cloudy) Comments RE[4]: Everybody knows JFFS2 is not perfect http://osnews.com/thread?297921 http://osnews.com/thread?297921
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. Sat, 26 Jan 2008 04:27:00 GMT donotreply@osnews.com (Cloudy) Comments RE: Linux FFS? http://osnews.com/thread?297976 http://osnews.com/thread?297976 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. Sun, 27 Jan 2008 11:27:00 GMT donotreply@osnews.com (Googol) Comments