From owner-freebsd-current@FreeBSD.ORG Fri May 26 02:50:55 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 6073816A4D2; Fri, 26 May 2006 02:50:55 +0000 (UTC) (envelope-from jim@netgate.com) Received: from netgate.com (mail.netgate.com [64.62.194.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF4F43D46; Fri, 26 May 2006 02:50:55 +0000 (GMT) (envelope-from jim@netgate.com) Received: from [192.168.2.184] (rrcs-67-52-77-54.west.biz.rr.com [67.52.77.54]) by netgate.com (Postfix) with ESMTP id 20DBB280073; Thu, 25 May 2006 19:50:51 -0700 (PDT) In-Reply-To: <20060525.141012.1683993116.imp@bsdimp.com> References: <3981.1148578569@critter.freebsd.dk> <4475EFC1.1020504@nortel.com> <1148580598.4475f2f677197@imp2-g19.free.fr> <20060525.141012.1683993116.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BEB3B54-4CAD-477D-B88C-AB32584B7A47@netgate.com> Content-Transfer-Encoding: 7bit From: Jim Thompson Date: Thu, 25 May 2006 16:50:49 -1000 To: "M. Warner Losh" X-Mailer: Apple Mail (2.750) X-Mailman-Approved-At: Fri, 26 May 2006 05:20:29 +0000 Cc: atrens@nortel.com, current@freebsd.org, olivier@gautherot.net, phk@phk.freebsd.dk, Alexander@Leidinger.net, small@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: Fri, 26 May 2006 02:50:57 -0000 On May 25, 2006, at 10:10 AM, M. Warner Losh wrote: > 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. its much worse than you present. superblocks, directory inodes for /var/log, inodes (never mind the blocks for the file) for /var/log/foo (mod/access time updates), etc. > : 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. though erasing a sector (for NAND flash) is a relatively slow operation. > 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. One problem with allowing excess fragmentation is that you might not be able to find a larger contiguous set of sectors, if your file/filesystem geometry requires same. This is why JFFS2 does GC.