Brainstorm: NAND flash

[Marcel Moolenaar]

On Feb 15, 2008, at 3:28 PM, Poul-Henning Kamp wrote:

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

The reason I thought this was good is that disks are
shipped without bad blocks visible to the "application".
That is: the norm is no bad blocks. With NAND flash
the norm is that bad blocks part of the deal. I thought
that dealing with bad blocks explicitly for NAND would
level the playing field and make it more consistent...

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

Can't this cause race conditions?

Suppose there happens to be a MBR in the first page at
offset 0. The MBR class could end up taking the provider,
when a wear-leveling geom should really take it.

>> 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!"

See above.

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

I'm ignorant of the obviousness of why sector mapping and
wear-leveling are to be done at the same time...

...and I presume you can't elaborate...



-- 
Marcel Moolenaar
xcllnt at mac.com