LWN: Comments on "LogFS"

LogFS

crucialp — Mon, 09 Jul 2007 02:20:22 +0000

This is a very interesting idea, and great to see how it could be included in mainline.

LogFS

Duncan — Thu, 24 May 2007 11:03:00 +0000

So we have a "wandering journal", much like reiser4 is supposed to have.
What would be the possibility of adding a plugin to reiser4 to make it
behave with flash requirements in mind as opposed to rotating disc
requirements?

Of course, reiser4 isn't in mainline yet, but supposedly, it's getting
closer, and with Namesys employees continuing to work toward that, and
with Hans himself (fs genius but political sand in the gears he often
seemed to be) out of the equation now, merging for 2.6.23 or .24 is
beginning to look both politically and technically possible. (See this
article from the April 26 LWN kernel page, "Filesystems: chunkfs and
reiser4", http://lwn.net/Articles/231585/ .)

Duncan

FTL and obsolete sectors

seanyoung — Fri, 18 May 2007 20:32:16 +0000

The logfs paper mentions obsoleting data in an ftl. I wrote a patch for that some time back but it didn't work all that well.

http://lwn.net/Articles/162776/

I introduced a new barrier request "forget" (obsolete would have been a better name). The ftl block device can used this information; however the barrier request caused more writes than without, as write requests before and after the barrier cannot be merged.

For example, the fat table itself is repeatedly written. If:

- write fat
- forget barrier request
- write fat again

Without the forget barrier the first write can be merged with second. So the only way to do this properly is by adding functionality to the block layer which can merge forget/obsolete requests. So the patch as describes actually increases I/O.

Another problem was that the in-kernel FTL layers are not used much nowadays, so the benefit would be limited. OTOH, the CompactFlash ATA command set does have an "erase" command which could possibly do exactly this -- I never verified this. However if it does compact flash memory would be faster and last longer.