Brainstorm: NAND flash

Marcel Moolenaar xcllnt at mac.com
Fri Feb 15 11:00:38 PST 2008


All,

I've been thinking about supporting NAND flash for disk storage
and I've come up with some initial thoughts for people to shoot
at. The intend of this thread is to align thoughts and for
people to tell me that they already have an implementation ;-)


NAND class
----------

NAND flash devices present themselves to the GEOM layer with
GEOMs of the NAND class. This is similar to HDDs presenting
themselves with GEOMs of the DISK class. The idea here is that
we need some additional I/O requests and also want to be able
to distinguish flash from disks.

GEOMs of class NAND don't have the mediasize and sectorsize
attributes (or they have them with value 0). The mediasize is
dependent upon the number of bad blocks, which is not being
dealt with at this level. NANDs don't have sectors.
Attributes of this class include:
	blockcount - the raw number of blocks
	blocksize - the number of bytes or pages in a block
	pagesize - the number of bytes in a page
	oobsize - the number of bytes per page used for OOB

The NAND class support BIO_DELETE. It'll also need something
for random access to the OOB data. For this we can introduce
BIO_READOOB and BIO_WRITEOOB. This allow byte-wise I/O. The
standard BIO_READ and BIO_WRITE operate on pages by default.

With the above, we have raw access to the NAND flash. That is
before any wear-leveling or sector mapping happens. A device
special file corresponding to GEOMs of this class can be used
by diagnostics and/or initialization tools.

Open issue: do we want this GEOM to deal with bad blocks?


WEARLEVEL class
---------------

GEOMs of the WEARLEVEL class (further referred to as WL class),
will taste GEOMs of the NAND class. In particular, they will
use the blockcount, blocksize, pagesize and oobsize in order
to determine whether a GEOM is suitable. The tasting process
will read OOB data to determine if wear-leveling is used. As
such, wear-leveling needs to be setup. For this a geom(8)
library exists. GEOMs of this class export the same variables
as GEOMs of the NAND class, but also has a non-0 mediasize.

The primary purpose of the WL class is to present a NAND
flash device that for which wear-leveling is not a concern
and that does not have any bad blocks. It can implement
different policies, such as block-based wear-leveling or
page-based  wear-leveling. All configurable through geom(8).


NANDDIDK class
-------------

GEOMs of the NANDDISK class (bad name, I know) attach to GEOMs
of either NAND or WEARLEVEL classes and present a consumer that
looks like a "regular" disk. It has the mediasize and sectorsize
attributes and not any of the blockcount, blocksize, pagesize
or oobsize attributes. Also BIO_READOOB and BIO_WRITEOOB are not
supported, though BIO_DELETE may be.

The primary purpose of this class is to provide standard sector
mapping for file systems that are not designed for NAND flash.
The mapping can be trivial.


NANDSIM class
-------------

Not needed in production, but it would be good to have a GEOM
that simulates a NAND flash and that keeps statistics. It is
configured by geom(8) and needs a provider for actual storage.
As such, you can use an underlying MD for storage and present
the GEOM layer with a NAND flash device. Statistics include
such things as erase count per block, read and write counts
per block or page.
Other features could include the simulation of power loss to
test algorithms used for wear-leveling and or sector mapping.


Let the discussion begin...

-- 
Marcel Moolenaar
xcllnt at mac.com




More information about the freebsd-geom mailing list