Messages in this thread | | | Date | Tue, 01 Apr 2008 08:56:45 +0300 | From | Artem Bityutskiy <> | Subject | Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) |
| |
Jörn Engel wrote: > 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.
> 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 (Артём Битюцкий) -- 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/
| |