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, 1 Apr 2008 11:25:48 +0200
From:	Jörn Engel <joern@...fs.org>
To:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
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)

On Tue, 1 April 2008 08:56:45 +0300, Artem Bityutskiy wrote:
>
> 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?

Correct.  I have a patch that caches this information in RAM, so the
worst-case scenario is to do the full scan once - if the filesystem is
near 100% full and performance is down the drain anyway.  The goal is
obviously to store that information on the medium.

And you get the obvious catch-22.  When writing out how much free space
exists in which blocks, you occupy some free space in one of those
blocks and obsolete some in another.  So by writing the data you have
just written changes and should be written again.

Takes a bit of thought to solve.

> 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.

So how do you solve the catch-22?

Jörn

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
--
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/