Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 May 2006 16:32:46 -1000
From:      Jim Thompson <jim@netgate.com>
To:        "James Mansion" <james@wgold.demon.co.uk>
Cc:        Alexander Leidinger <Alexander@Leidinger.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Andrew Atrens <atrens@nortel.com>, small@freebsd.org, current@freebsd.org
Subject:   Re: FreeBSD's embedded agenda
Message-ID:  <2EFA38F2-77CE-429D-A9DE-9E764EEAA8CB@netgate.com>
In-Reply-To: <HCEPKPMCAJLDGJIBCLGHAEFIFGAA.james@wgold.demon.co.uk>
References:  <HCEPKPMCAJLDGJIBCLGHAEFIFGAA.james@wgold.demon.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2EFA38F2-77CE-429D-A9DE-9E764EEAA8CB>