Jörn Engel wrote:
quoted text
> Code size difference is huge.  Ubi weighs some 11kloc, ubifs some 30,
> logfs some 8.
Please, lets refrain form unfair comparisons like this before logfs is
finished. Also, when you compare, please, take into account that UBI/UBIFS
has many times more commentaries in the code.

quoted text
> Ubi scales linearly, as it does a large scan at init time.  It is still
> reasonably fast, as it reads just a few bytes worth of header per block.
> Logfs mounts in O(1) but will currently become mindbogglingly slow when
> the filesystem nears 100% full and write are purely random.  Not that
> any other flash filesystem would perform well under these conditions -
> it is the known worst case scenario.
I asked you some time ago to describe how you maintain per-eraseblock
space accounting [1]. E.g., how you select an eraseblock for garbage
collection, how do you store the accounting information.

You said you find eraseblocks by scanning. This means logfs is not
really scalable because you may spend ages before you find anything
appropriate. When the FS is almost full, yo need to scan nearly
whole flash to find an eraseblock? So if I mount a nearly full 
FS, and start writing, I'll get my request handled when nearly whole
media is scanned?

UBIFS stores per-eraseblock information on the media in a B-tree, and
it also has lists of empty/dirty eraseblocks, which allow to very quickly
find the best eraseblock to garbage-collect or to write to.

[1] http://lkml.org/lkml/2007/8/8/333

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/