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]

Message-ID: <47F202CD.4000804@yandex.ru>
Date:	Tue, 01 Apr 2008 12:39:25 +0300
From:	Artem Bityutskiy <dedekind@...dex.ru>
To:	Jörn Engel <joern@...fs.org>
CC:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>,
	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:
> 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.

Anyway, if you do not store this information on the flash, you are going
to scan to acquire it. You may have caches, but they do not have to have
information (may be empty), then you scan. This will lead to scalability
problems at some point anyway.

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

I'm not sure what you mean. In UBIFS we have lprops area, where we store
per-LEB accounting. UBI lets it possible to have it on a fixed position.
The accounting is a separate B-tree. Lprops area has its own independent
garbage collector. You should probably refer the white paper for more
information.

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