Terry Moore wrote:
> Depending on the media, writing a block even twice can cause non-local
> errors.  This is a major issue when working with NAND flash.  The chip
> spec says you can write 10 times before erasing, but in practice
> (i.e., I have some personal experience in this area) writing more than
> once makes the error rate unacceptable for the next layer up, even if
> you have ECC at the next layer, because of the nature of the failures,
> and practical details such as the difficulty of testing a large
> NAND-flash device on production testers (you need the ECC for
> recovering from manufacturing flaws -- you don't want to waste it on
> recovering from flaws induced by writing a block more than once).
>
> My advice is, unless you can enlist a NAND flash expert in the quest:
> start with NOR flash, and don't expect your NOR flash technology to be
> your solution for NAND.  Definitely don't reason from anything you
> know about NOR flash to NAND flash, you really need to forget all that
> when working with NAND.

Okay, thanks for the warnings.

However, if there is some obvious thing I can do which will make it
easier for NAND to make use of the same framework, then I'd rather do
that, than go in a different direction that precludes it entirely.

The fact that writing media twice before erase  can cause errors is
substantive.  It suggests that at a minimum, a block oriented approach
to NAND is going to work *even* less well than it would for NOR.  So to
me it underscores my point, which is that details about the underlying
devices need to be exposed to a filesystem, rather than hidden from it.

Btw, this doesn't guarantee that what I do will be useful/usable for
NAND later, but it certainly improves the odds.  So I don't want to
ignore NAND completely.  Unless NAND is so totally different from NOR
that there is no sane common abstraction.  I *think* the existence of
the MTD framework in Linux is evidence that the notion that the
abstractions have *something* in common is not totally insane.

    -- Garrett
>
> Also, this is an area where the giants have all kinds of patents, so
> one must be careful, or judgement-proof.  (This is the reason my
> company files for patents, more or less in self-defense.)
>
> --Terry
>
> At 06:06 PM 3/23/2006 +0000, David Brownlee wrote:
>> On Thu, 23 Mar 2006, Charles M. Hannum wrote:
>>
>>> On Wed, Mar 22, 2006 at 06:45:08PM +0000, David Brownlee wrote:
>>>>         From a hardware perspective you should be able to perform
>>>>         sub-block writes down to the word level. A perfect example
>>>>         of that usage would be a an app performing synchronous
>>>>         appending writes to a logfile. Providing you are not
>>>>         _clearing_ any bit in the current block you can just 'write
>>>>         over' the current values (assuming standard flash).
>>>
>>> Unfortunately, current file systems like FFS can't do this, because
>>> they
>>> zero all the unused data in a block, and rewrite it every time. 
>>> This is
>>> a good example of why a flash-aware file system is important -- you can
>>> save a lot of wear, and gain a lot performance here.
>>
>>         Presumably that could be handled by having the layer
>>         underneath the filesystem test if a write only sets bits
>>         in an existing block, and if so just go ahead and 'overwrite'
>>         that block. It still doesn't make existing filesystems a good
>>         fit to flash devices...
>>
>> -- 
>>                 David/absolute       -- www.NetBSD.org: No hype
>> required --


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191