Message-ID: <20070508114129.GA20637@lazybastard.org>
Date:	Tue, 8 May 2007 13:41:30 +0200
From:	Jörn Engel <joern@...ybastard.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andrew Morton <akpm@...l.org>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
	David Chinner <dgc@....com>
Subject: Re: [PATCH 0/2] LogFS take two

On Tue, 8 May 2007 09:39:37 +0200, Thomas Gleixner wrote:
> 
> > Motivation 2:
> > 
> > Flash is becoming increasingly common in standard PC hardware.  Nearly
> > a dozen different manufacturers have announced Solid State Disks
> > (SSDs), the OLPC and the Intel Classmate no longer contain hard disks
> > and ASUS announced a flash-only Laptop series for regular consumers.
> 
> With a hardware controller which allows no direct access to the flash.
> 
> > And that doesn't even mention the ubiquitous USB-Sticks, SD-Cards,
> > etc.
> 
> which again do not allow direct access to the flash

I know that and I have talked to manufacturers.  Not allowing direct
access is common practice today, but I didn't encounter much opposition
against allowing it in the future.  What appears to be holding them back
is that there would be absolutely no value in it right now.  With direct
flash access, which filesystem should users choose for their 32GB SSD?

> > Flash behaves significantly different to hard disks.  In order to use
> > flash, the current standard practice is to add an emulation layer and
> > an old-fashioned hard disk filesystem.  As can be expected, this is
> > eating up some of the benefits flash can offer over hard disks.
> > 
> > In principle it is possible to achieve better performance with a flash
> > filesystem than with the current emulated approach. 
> 
> Err, where does JFFS2 use a block emulation layer ?

It doesn't.  Motivation 2 is about SSDs, USB sticks, SD-Cards, etc.
JFFS2 is motivation 1.

> Are you going to make logfs play with UBI ?

It is not very high on my priority list.

> > Handling of read/write/erase errors currently is BUG().  It is on my
> > list, no need to remind me. :)
> > 
> > Overall I consider this to be -mm material.
> 
> I don't. It seems fs developers tend to have their own view of how to
> get stuff mainline.

Maybe.  My view is that I have to solve any problems found until people
consider the code good enough by whatever metric.  The final criterium
appears to be quite fuzzy.

> The code is far from being useful on real world hardware. The error
> handling via BUG() is just making it useless. 

On NOR hardware?  How many write/erase failures does one commonly
encounter there?  Those things will need to get sorted, sure.  But
I doubt whether LogFS is useless on _all_ hardware because of this.

> Also please fix the coding style and other issues from the seperate
> review.

Sure.

> Some useful comments would make a functional review way easier.

Common problem.  Implementor doesn't know what comments would be useful
and reviewer doesn't know where to start without useful comments.  I
will try to add some and would love to see suggestions.

> >   It would be good to get
> > some review and have the usual allyesconfig crowd build it 
> 
> make allyesconfig does not work for you ?

It does.  But I don't have a coverity license, just to give one example.

Jörn

-- 
The wise man seeks everything in himself; the ignorant man tries to get
everything from somebody else.
-- unknown
-
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/

Powered by blists - more mailing lists