From owner-freebsd-current@FreeBSD.ORG Thu May 25 23:29:16 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 DEBAF16A63D; Thu, 25 May 2006 23:29:16 +0000 (UTC) (envelope-from james@wgold.demon.co.uk) Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7833143D46; Thu, 25 May 2006 23:29:16 +0000 (GMT) (envelope-from james@wgold.demon.co.uk) Received: from wgold.demon.co.uk ([158.152.96.124] helo=thor) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1FjPGU-000AKi-If; Thu, 25 May 2006 23:29:15 +0000 Received: from 127.0.0.1 by thor ([127.0.0.1] running VPOP3) with SMTP; Fri, 26 May 2006 00:03:54 +0100 From: "James Mansion" To: "Andrew Atrens" , "Poul-Henning Kamp" Date: Fri, 26 May 2006 00:03:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4475E99C.5000502@nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Server: VPOP3 V1.5.0k - Registered X-Mailman-Approved-At: Thu, 25 May 2006 23:32:46 +0000 Cc: Alexander Leidinger , 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 23:29:17 -0000 > It would support wear-levelling I think this might in practice be a red-herring. 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. 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).