From owner-freebsd-current@FreeBSD.ORG Fri May 26 02:32:51 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 9F40016A8EC; Fri, 26 May 2006 02:32:51 +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 649EF43D4C; Fri, 26 May 2006 02:32:51 +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 1CDF7280073; Thu, 25 May 2006 19:32:47 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EFA38F2-77CE-429D-A9DE-9E764EEAA8CB@netgate.com> Content-Transfer-Encoding: 7bit From: Jim Thompson Date: Thu, 25 May 2006 16:32:46 -1000 To: "James Mansion" X-Mailer: Apple Mail (2.750) X-Mailman-Approved-At: Fri, 26 May 2006 02:36:16 +0000 Cc: Alexander Leidinger , Poul-Henning Kamp , Andrew Atrens , 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: Fri, 26 May 2006 02:32:52 -0000 On May 25, 2006, at 1:03 PM, James Mansion wrote: >> It would support wear-levelling > > I think this might in practice be a red-herring. If you're assuming CF, possibly. If you're assuming a lower level flash interface, no. > If you could convince the system to set aside an amount > of RAM for dirty disk buffers and to write them all when > its filled or on application demand (and in a way that > preseves integrity like soft updates) so that for any > given flush each sector is written at most once, then > you can run for years for most CF cards and most practical > usage patterns that don't really demand a hard disk. embedded systems are constrained in memory size, too. > Assume you have cron drive a flush once an hour and > consider how long until a sector dies, even if the drive > itself does no wear levelling at all (and I believe some > do it internally). internal wear-leveling CF: yes otherwise: not typically. Might want to re-think your argument in terms of a system with 32MB of ram and 4MB of NAND or NOR flash.