Re: LogFS merge

Re: LogFS merge

[matthieu castet]

Hi,

On Fri, May 2, 2008 at 4:32 PM, Jörn Engel <joern@logfs.org> wrote:
 >  not being familiar with either maintaining my own git tree or the -next
 >  process, I'd still like to get logfs into mainline.  It has gone through
 >  six rounds of reviews and the last has been mostly about crossing some
 >  i's here and dotting some t's there.
 >
 >  So should it simmer in -next and -mm for another month?  Should it go
 >  straight into -linus?
Shouldn't this get review by mtd guys first ?

Also for info, there have been some issue raised by the ubifs developer [1].

Matthieu

[1] http://thread.gmane.org/gmane.linux.kernel/658740/focus=660392

Re: LogFS merge

[Jörn Engel]

On Sat, 3 May 2008 11:29:43 +0200, matthieu castet wrote:
>
> Shouldn't this get review by mtd guys first ?

They were on Cc: on most of the review rounds.

> Also for info, there have been some issue raised by the ubifs developer [1].

I am aware of them.  When ignoring FUD and personal things (Artem and I
have a history), it should come down to roughly this:

1.
Ubifs takes the easy approach and uses ubi for wear leveling, bad block
handling, ets.  Saves a ton of work, gives quick results and is limited
by ubi scan time, which is O(n).

Logfs ignores ubi and does wear leveling, bad block handling, etc.
itself.  Bad block handling in particular is not too robust yet.  If you
expect blocks to rot away after mkfs time, logfs is a bad choice.

2.
Logfs still scans the medium.  It currently does not store free space
maps and has to search for free space the hard way.  I still have a
patch to keep the map in-memory, which will avoid any rescans.  But the
real deal is to store it in a file with some additional tricks to make
things work in a log-structured fashion.  Not done yet.

Ubifs has a seperate region to store its free space map, which has its
own GC.  Wear leveling is dealt with through ubi.  Again, ubi makes life
easier.

3. Code size.

4. Mount time.  I don't see any numbers I could quote, but I believe
ubifs is somewhere close to a second.  Does anyone know?  Logfs is in
the 10-60ms range.

5.
Ubifs has write-back caching for file data.  Their benchmarks blow jffs2
or logfs out of the water, which isn't surprising when comparing DRAM to
flash.

Logfs has write-back caching for metadata (indirect blocks, etc.) but
immediatly writes normal data.  Some embedded folks actually prefer this
approach, as it is more deterministic.  For most uses it simply throws
away some performance.  Extending caching to normal data isn't too hard
and fairly high on my list.

6.
"Logfs isn't finished yet."
My usual answer to that is that Linux isn't finished yet either.  We're
still improving performance, adding hardware support and fixing bugs
some 15 years after people started using it.  The question is not
whether there are improvements left, but whether it is good enough
already.

Jörn

-- 
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello

Re: LogFS merge

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 708 bytes --]

On Sat, 3 May 2008, Jörn Engel wrote:
> 1.
> Ubifs takes the easy approach and uses ubi for wear leveling, bad block
> handling, ets.  Saves a ton of work, gives quick results and is limited
> by ubi scan time, which is O(n).

Which is easy enough to fix.

> Logfs ignores ubi and does wear leveling, bad block handling, etc.
> itself.  Bad block handling in particular is not too robust yet.  If you
> expect blocks to rot away after mkfs time, logfs is a bad choice.

It's a matter of fact that especially on NAND flash blocks become bad
over time, i.e. after mkfs. So that's a pretty crucial feature which
needs to be complete and robust before it's declared to be usable on
such devices.

Thanks,
	tglx

Re: LogFS merge

[Josh Boyer]

On Sun, 4 May 2008 18:20:23 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> > Logfs ignores ubi and does wear leveling, bad block handling, etc.
> > itself.  Bad block handling in particular is not too robust yet.  If you
> > expect blocks to rot away after mkfs time, logfs is a bad choice.
> 
> It's a matter of fact that especially on NAND flash blocks become bad
> over time, i.e. after mkfs. So that's a pretty crucial feature which
> needs to be complete and robust before it's declared to be usable on
> such devices.

I agree.  LogFS seems quite impressive in its performance, however I'm
wondering how much redesign and rewrite would be needed in the code to
fix the bad block handling.  Maybe it's not so much and I'm overly
paranoid, but having at least some idea of what it would take might
help.  You could add it to Documentation/filesystems/LogFS.txt as a
TODO.

josh