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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080401091945.GB7465@logfs.org>
Date:	Tue, 1 Apr 2008 11:19:46 +0200
From:	Jörn Engel <joern@...fs.org>
To:	Artem Bityutskiy <dedekind@...dex.ru>
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: Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

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

Write-back of metadata: yes.  Write-back of data: currently not.
Compression: yes.

> Is this patch the right one we should look at:
> http://logfs.org/logfs/patches

Yes.

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

You are right, bad-block handling is easier to implement in ubi than in
a filesystem.  That is one of the real benefits from using ubi.  And if
my other arguments about ubi would have been handled instead of answered
with flames, I would likely be using it as well.

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

fs/logfs/gc.c
Grep for s_ec_list.  It is currently quite aggressive and keeps the
spread between maximum erasecount and minimum erasecount at about 40.
Should become an mkfs option one of these days.

There is no dedicated subsystem for wear leveling.  There simply isn't
that much to do.

Jörn

-- 
Premature optimization is the root of all evil.
-- Donald Knuth
--
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/