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.

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