Date: Thu, 25 May 2006 21:02:13 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Andrew Atrens" <atrens@nortel.com> Cc: Alexander Leidinger <Alexander@Leidinger.net>, Jim Thompson <jim@netgate.com>, small@freebsd.org, current@freebsd.org Subject: Re: FreeBSD's embedded agenda Message-ID: <4350.1148583733@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 25 May 2006 13:56:17 EDT." <4475EFC1.1020504@nortel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4475EFC1.1020504@nortel.com>, "Andrew Atrens" writes: >>>Said kernel would have a low level driver that makes plain >>>old flash chips look (and behave) like a disk. It would support >>>wear-levelling, [...] >>> >>>Then you could throw FFS on top of that. >> >> This is exactly what you do not want to do. >> >> You want to write a flash friendly filesystem which knows what >> a flash is, and which does the wear levelling internally. >> >> 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 main one is that the flash adaptation layer does not have the full information to work with for deciding wear-leveling decisions and the filesystem has no idea what the optimal block allocation strategy is for the flash device. Flash devices have no seek time penalty, and therefore the block allocation should focus on wear-leveling rather than seek time optimization. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4350.1148583733>