Brainstorm: NAND flash

Poul-Henning Kamp phk at phk.freebsd.dk
Fri Feb 15 15:48:21 PST 2008


In message <4A4329EB-B8EF-4CDA-98C0-4753289C4788 at mac.com>, Marcel Moolenaar wri
tes:

>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. 

Mediasize is about addressability, not about usability, so this
assumption is wrong.

A GEOM provider is just an addressable array of sectors, it
doesn't guarantee that you can read them all or write them
all, as is indeed the case when your disk develops a bad sector.

NAND is only special due to the OOB stuff, the main page array
is just a pretty spotty disk, for all GEOM cares.

>dealt with at this level. NANDs don't have sectors.
>Attributes of this class include:
>	blockcount - the raw number of blocks

This goes in mediasize (as a byte count)

>	blocksize - the number of bytes or pages in a block

This goes in sectorsize.

>	pagesize - the number of bytes in a page
>	oobsize - the number of bytes per page used for OOB

These two are secondary attributes which are not likely to change
easily for a given NAND, so they should be handled by the BIO_GETATTR
(as "NAND::PAGESIZE" and "NAND::OOBSIZE" for instance).

>For this we can introduce
>BIO_READOOB and BIO_WRITEOOB.

Yes, this sound sensible.

The original plan is that all BIO_ operations are power of two and
providers should have a bitmap of which they support, (G_PF_CANDELETE
is a mistake in this respect) so this shouldn't be a problem.

In general we should not introduce new BIO_ operations
without reason, but these two are very reasonable.

>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.

Yes, given suitable ioctls to geom_dev, for the new BIO_*OOB.

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

I'm not sure I understand this question.  GEOM doesn't know about
bad blocks, if you try to use them, GEOM happily transports the
resulting error code back, but it does not care if the error code
is "read error" or "values of beta gives rise to dom!"

>WEARLEVEL class
>---------------

Sounds good.   I'm under NDA on M-Systems algorithm and Sandisk
is sueing left and right on those patents.

>NANDDIDK class
>-------------

>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.

I don't understand why this would be necessary, this is normally
done in the wearleveling class (for reasons that should be obvious),
so why do you want to split it into a separate class ?

>NANDSIM class
>-------------
>
>Not needed in production, but it would be good to have a GEOM
>that simulates a NAND flash and that keeps statistics.

A very good idea.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.


More information about the freebsd-geom mailing list