Date: Tue, 28 Oct 2008 09:53:56 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: stas@FreeBSD.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, xcllnt@mac.com, src-committers@FreeBSD.org Subject: Re: svn commit: r184251 - in head/sys: conf dev/cfi sys Message-ID: <20081028.095356.2040345174.imp@bsdimp.com> In-Reply-To: <20081028104435.50b3fb0f.stas@FreeBSD.org> References: <0BBCA616-4F9D-48D5-9360-CACA69480632@mac.com> <20081027.214547.709404828.imp@bsdimp.com> <20081028104435.50b3fb0f.stas@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20081028104435.50b3fb0f.stas@FreeBSD.org>
Stanislav Sedov <stas@FreeBSD.org> writes:
: On Mon, 27 Oct 2008 21:45:47 -0600 (MDT)
: "M. Warner Losh" <imp@bsdimp.com> mentioned:
:
: >
: > I tend to think that we should handle the partitioning in GEOM, with
: > higher level things figuring the rest out. We should expose flash,
: > and its properties upstream in GEOM, but not have a separate layer for
: > flash ala mdt.
: >
:
: Yeah, GEOM is the right place for this kind of stuff, indeed. Wear levering
: and similar things could be provided via GEOM too, probably.
Especially if the wear averaging were optional. Then we could put
'legacy' file systems on top of the wear averaging layer, but could
also develop more optimized file systems with wear averaging built
in. Which one to use can also be highly application specific for the
best performance. The story from the Linux world indicates that many
applications just don't matter, but the ones that do often depend on a
specific type of flash is used. NAND and NOR memories have very
different performance characteristics, and papers presented at Linux
conferences show gains for teams that have created new file systems
for the specific type of flash.
Right now, I expose the SPI flash as 1056 byte blocks (since that's
the size of the block). A wear averaging layer would write metadata
in the 32 bytes and expose 1024 or 512 byte blocks...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081028.095356.2040345174.imp>