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

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

Yes.

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

quoted text
> >>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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/