ts-7000
[Top] [All Lists]

Re: [ts-7000] Re: Flash wear level

To:
Subject: Re: [ts-7000] Re: Flash wear level
From: Alan Dayley <>
Date: Mon, 9 Feb 2009 22:44:30 -0700
On Mon, Feb 9, 2009 at 12:30 PM, Michael Schmidt
<> wrote:
>
> Well at first I was going to say that it would also seem to imply
> reduced overall flash lifetime, as internally the wear-leveler is doing
> additional erases and writes on blocks that otherwise would be left
> alone.  But after running a simple thought experiment I can't see how it
> would even provide any better wear-leveling.
>
> For example, suppose you had a flash with only 4 blocks, and each has a
> lifetime of 10 writes.  If 3 blocks are in use, then if you repeatedly
> re-write the 4th block it will wear out faster.  Specifically, you will
> get 10 writes before the 4th block is worn out and (since there are only
> 4 blocks) the device is declared unusable.  But if you erase other
> blocks does it really help?   No, because whatever block you erase to
> write the 4th block, you now have to write into the 4th block.  Now
> after 10 writes, two blocks will be bad instead of one.
>
> If only 2 blocks are in use, then alternating between blocks 3 and 4
> will give a total of 20 writes until the flash is full.  But if you
> repeatedly erase block 1 or 2 in order to put the new block, you still
> have to put the contents of that block somewhere, either block 3 or 4.
> So now you get 30 writes, but 10 of those are writes required to move a
> block.
>
> Hopefully the above description of how this works either has been
> simplified and is missing the key to what makes it work, or else whoever
> designed this algorithm is better/more rigorous at their math than me. ;-)

Your example is missing an important piece that I mentioned before but
did not elaborate: spare blocks.

Spare blocks are physical flash locations that the controller holds in
pristine reserve or uses as a pool for wear-leveling moves.  The
spares come from the difference between the advertised size of the
flash, in base 10, and the actual flash capacity, in base 16.  (See
http://en.wikipedia.org/wiki/Binary_prefix#Flash_drives).

So, let's use your simplified example of only 4 blocks again but this
time add an additional spare block.  We are also using a VERY
simplified concept of a wear leveling algorithm that only moves data
when being written by the host.

As in your example:
- The host system "sees" only 4 usable blocks.
- Three of the blocks are used with static (unchanging) data.
- The host system writes a small file over and over to the 4th block.

Dynamic wear leveling:
- Host writes file to block 4
-- Controller reads currently stored block 4
-- Controller combines current block 4 data in RAM with data from the host
-- Controller writes combined old and new data to the block spare
-- Controller maps what was the spare as block 4
-- Controller maps what was block 4 as the spare and erases it
- Write operation complete
- The file write can take place 20 times because we are wear leveling
across two blocks, apparently doubling the write endurance of a single
block

Static wear leveling:
- Host writes file
-- Controller reads currently stored block 4
-- Controller combines current block 4 data in RAM with data from the host
-- Controller determines which block of 1, 2, 3 or 5 (spare) to write
into based on logged write counts or some other criteria
--- Controller decides to move the data from block 2 to block 5 and
maps 5 as the 2'
--- Controller then writes the new data into block 2 and maps it as 4'
--- Controller then erases block 4 and maps it as 5', the new spare
- Write operation complete
- The file write can take place 25 times because we are wear leveling
across 5 blocks, again increasing the aparent write endurance of the
single block
-- (5 blocks in pool / 2 blocks written per host write) * 10 writes
per block = 25 apparent writes

Gaining only 5 more writes looks quite small here but our play numbers
are small too.  Even then, remember that +5 is a 25% improvement over
the dynamic wear leveling even in this very fake scenario.  25% is
nothing to shake a stick at!

Real wear leveling algorithms don't necessarily move on every write
and use far more sophisticated decision making, including many other
factors to stretch the life of the flash.  For example, some
controllers perform extra wear leveling and/or error correction on
areas of the flash that usually get high activity.  Or the controller
may reserve 5% of the blocks as spares instead of just 2%.

There are a great many things the controller can do to enhance
endurance.  And we have not touched on ECC for read error correction,
flash disturbs and other such topics, which a good controller will
also take care of.  It's a fascinating area for thought and design if
one wants or must take the time!

BTW, spare blocks were not invented by flash designers.  Standard
rotating hard drives needed them decades ago and still use them today!

Alan


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
     
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU