linux-kernel - Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 01 Apr 2008 08:56:45 +0300
From:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
To:	Jörn Engel <joern@...fs.org>
CC:	Adrian Hunter <ext-adrian.hunter@...ia.com>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	LKML <linux-kernel@...r.kernel.org>, joern@...ybastard.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/