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>