From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: [PATCH] LogFS take three Date: Thu, 17 May 2007 16:43:59 +0800 Message-ID: <1179391440.2859.447.camel@shinybook.infradead.org> References: <20070515151919.GA32510@lazybastard.org> <20070515133759.9ee434a2.akpm@linux-foundation.org> <1179317240.2859.222.camel@shinybook.infradead.org> <20070516083408.dcd9dd78.akpm@linux-foundation.org> <1179330596.2859.248.camel@shinybook.infradead.org> <20070516164158.GB8113@lazybastard.org> <7fe698080705162312t4e7ed90byd10ef8e664027b17@mail.gmail.com> <1179383117.2859.416.camel@shinybook.infradead.org> <7fe698080705170120w18fe5521oa685cf248a45e1c6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-1?Q?J=F6rn?= Engel , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Albert Cahalan , Thomas Gleixner , Jan Engelhardt , Evgeniy Polyakov , Pekka Enberg , Greg KH , Ingo Oeser To: Dongjun Shin Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:43337 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752347AbXEQIoL (ORCPT ); Thu, 17 May 2007 04:44:11 -0400 In-Reply-To: <7fe698080705170120w18fe5521oa685cf248a45e1c6@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2007-05-17 at 17:20 +0900, Dongjun Shin wrote: > There are, of course, cases where direct access are better. > However, as the demand for capacity, reliability and high performance > for the flash storage increases, the use of FTL with embedded control= ler > would be inevitable. >=20 > - The complexity/cost of host-side SW (like JFFS2/MTD) will increase = due to > the use of multiple flash in parallel and the use of high degree ECC = algorithm. > There are other things like bad block handling and wear-leveling issu= es > which has been recently touched by UBI with added SW complexity. You don't get rid of that complexity by offloading it to a =C2=B5contro= ller.=20 The only thing you achieve that way is making sure it's quite likely to be done badly, and making it impossible to debug. > - In contrast to the embedded environment where CPU and flash is dire= ctly > connected, the I/O path between CPU and flash in PC environment is lo= nger. > The latency for SW handshaking between CPU and flash will also be lon= ger, > which would make the performance optimization harder. Do it the na=C3=AFve way with a single byte push/pull and waggling the control lines separately, and what you say is true -- but you can have flash controllers which assist with data transfer but still give you essentially 'raw' access to the chip. With the CAF=C3=89 controller designed for the OLPC machine, we can spe= w data across the PCI bus just as fast as we can suck it off the flash chip. > As I mentioned, some techniques like log-structured filesystem could > perform generally better on any kind of flash-based storage with FTL. > Although there are many kinds of FTL, it is commonly true that > it performs well under workload where sequential write is dominant. Yes, it's certainly possible that we _could_ write a file system which is specifically targeted at FTL -- I was just wondering why anyone woul= d _bother_ :) I've seen an interesting file system which does have a kind of FTL internally as its lowest layer, and which build on that using 'virtual' sectors for file extents. Now that _does_ have its advantages -- but it doesn't go as far as pretending to be a 'normal' block device; it's its own special thing for internal use within that file system. =20 > I also expect that FTL for PC environment will have better quality sp= ec > than the disposable storage. There really is no reason why FTL has to be done badly; just as there's no _reason_ why hardware vendors have to give us crappy bsVendorCode. Nevertheless, that's the way the world tends to be. So good luck shipping with that :) --=20 dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html