From owner-freebsd-current@FreeBSD.ORG Thu May 25 20:10:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3736316C030; Thu, 25 May 2006 20:10:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37B7D43D7F; Thu, 25 May 2006 20:10:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k4PKABMf036775; Thu, 25 May 2006 14:10:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 25 May 2006 14:10:12 -0600 (MDT) Message-Id: <20060525.141012.1683993116.imp@bsdimp.com> To: olivier@gautherot.net From: "M. Warner Losh" In-Reply-To: <1148580598.4475f2f677197@imp2-g19.free.fr> References: <3981.1148578569@critter.freebsd.dk> <4475EFC1.1020504@nortel.com> <1148580598.4475f2f677197@imp2-g19.free.fr> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alexander@Leidinger.net, phk@phk.freebsd.dk, atrens@nortel.com, small@freebsd.org, current@freebsd.org Subject: Re: FreeBSD's embedded agenda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 20:10:50 -0000 In message: <1148580598.4475f2f677197@imp2-g19.free.fr> Olivier Gautherot writes: : Hi Andrew! : : > [...] : > > The reason Flash Adaptation Layers came about in the first place : > > is that W95 didn't support anything but FAT. : > : > : > Hmm. I was thinking about partitioning the problem actually. Make flash : > look like a disk and then you can put any filesystem on it that you : > want. Seems a heck of a lot simpler .. and I'm not sure if I see any : > drawbacks to doing it that way ... : : The drawback is the following: what would happen if you had an application : opening-writing-closing a file in /var/log on a regular basis? The block : would decay with time, with chances that your log even gets corrupted. : That's why Flash drivers have to spread write accesses across the device : (what FFS doesn't naturally do). Also, there is a constraint regarding : the changes allowed: on NAND flash, you can write a 0 on a bit but have : to erase the full block to write a 1 back. : : Don't forget that Flash doesn't suffer from mechanical delays so there : is no harm in fragmenting the filesystem: this would be another feature. There's at least one implementation of a geom_nand layer that tries to wear average blocks from a pool it keeps. However, it would be far better if it could get hints from the file system layer when blocks were freed. Once you get to that level of abstraction, you might as well just do all the work yourself. It gets kinda hairy to do it generically for any filesystem. Warner