linux-kernel - 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: <47F1C78D.2050300@yandex.ru>
Date:	Tue, 01 Apr 2008 08:26:37 +0300
From:	Artem Bityutskiy <dedekind@...dex.ru>
To:	Jörn Engel <joern@...fs.org>
CC:	Adrian Hunter <ext-adrian.hunter@...ia.com>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>, joern@...ybastard.org
Subject: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

I've renamed the thread because I do not like this flamish discussion
to me mixed with the technical one.

Jörn Engel wrote:
> Shiny numbers!  Performance has improved significantly in the last six
> month.  Still worth a closer look.
We'll re-run them. Does logfs support write-back? Does it support compression?
Is this patch the right one we should look at:

>> 3. logfs does not seem to have bad-block handling.
> 
> Bad blocks at mkfs time are handled, blocks turning bad later on aren't
> yet.

This basically means it is unfinished. Handling dynamic bad blocks is a *must*
if you are going to work on NAND, especially on MLC NAND which are not as
reliable as SLC.

I think you should bluntly say about this when you submit patches to prevent
people from starting using it in production.

UBI handles I/O errors and gracefully recovers the data. And it will not be
easy to do this in LogFS at all. If you have write error in the middle of an
eraseblock, you have to recover data which means correcting all the indexing
data structures which refer the data you recover. Correcting them may require
garbage collection, because you have to update them out of place. And what
do you do if you are already in the middle of doing garbage-collection?

In other words, I believe it will take a lot of time and efforts to implement
this. And any speculation about the number of lines of code makes no sense
before you finish your work.

>> 4. logfs does not seem to have wear-leveling.
> It does.
Could you please point the core functions which implement this and shortly
describe the algorithm?

I grep'ed for "wear" and "leveling" and found only one match. Where should
I look at?

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