[Beowulf] SSD prices - q: how many writes/erases???

[Nifty Tom Mitchell]

On Fri, Dec 12, 2008 at 04:35:26PM +0100, Peter Jakobi wrote:
> 
> > > Reliability is another question and I posted a quick response to
> > > this list in a different email.
> > 
> > This being my big concern with flash.
> 
> related is this topic on SSD / flashes:
> 
> what's the life time when changing the same file frequently?
> aka "mapping block writes to cell erases" 
> aka "how  many  erases  are  possible?"
> 
> In  the  days  of  yore, that was the limitation on  using  flash,  as
> writing  a block to the same physical location on the flash (for  some
> to  be defined sense of physical location :)) requires a whole slew of
> blocks  (let's  call  it a 'cell', maybe containing a  few  dozens  or
> thousands of blocks?) to be erased and a subset of them to be written.
> 
> Does  anyone  have current and uptodate info or researched this  issue
> already?
> 
> 
> ===
> Some  of  the  questions I see before checking recent  kernel  sources
> would be:
> 
> -  is  there some remapping in the hardware of the ide emulation  chip
> space of say compactflash or usb sticks?
> 
> - is part of this possible in the ide-emulation in the kernel?
> 
> -  or  is  part of this in the filesystem, that is  suddenly  after  a
> decade  or  more, the fs has to cope again with frequent  bad  blocks,
> like the old bad blocks lists of the SCSI days 2 decades past?
> 
> [basically:  is there some 'newish' balancing to limit /  redistribute
> the  number of erases over all cells? Is there a way to relocate cells
> that resist erasing, ...?]
> 
> -  can  I  place a filesystem containing some files  that  are  always
> rewritten on flash and use say ordinary ext2 or vfat for this?
> 
> - might I even be able to SWAP on flash nowadays?
> 
> -  Or do I still have to do voodoo with FUSE overlays or other  tricks
> to  reduce the number of writes leading to cell erases? Maybe check if
> there's  a  real  log-structured filesystem available, that  has  seen
> production  use outside of labs (and doesn't fail by keeping its  some
> of its frequently changing metadata in always in the same location).
> 
> -- 
> cu
> Peter
> jakobi at acm.org

Sun and Micron recently reported a million plus cycles for a single level flash
product.  Current shipping product is on the order of 100000 cycles.

A spinning 54000 rpm disk could possibly hammer a single block to the
current limit in about 15 min or so...   in a write never read scenario...
but that would never happen in reality.  This appears to imply that
old spinning disk oriented file system structures would quickly cause
failure were it not for buffering.  File systems like ext[23] combined
with kernel data buffering might never touch a disk but once if 100000
writes were to be issued back to back to back.

Swap IO will also be subject to buffering/ cache.   i.e. if a page was constantly being 
touched it would not be pushed to physical swap media -- other pages would (about once).

Laptop suspend to swap... 100000 cycles -- 5 times an hour, 8 hour work day
might be 6 years.

Files that never change would be a reservoir of good bits.  A lazy daemon that
rewrote (with a copy strategy) the oldest file one at a time would expose good bits
and sequester bits with larger rw cycle history.  Many complex file system optimizations
for data locality could be eliminated in ext[23] code to advantage.

Metadata writes to a journal would insulate the meta data of the file system itself
from numerous rewrites.

Spinning media has a number of strong and well tested ECC and defect
management features that flash does not yet have (as far as I know).
Disk controllers hide this stuff from the OS today... older unix systems
had dumber controllers so this stuff could be dusted off.

I suspect that the current IO and filesystem code in the Linux system is 
less stressful than a first blush look at flash might lead one to believe.

I have recently added swap to an SD card partion on my OLPC XO.
Nine dollars of SD flash based swap goes a long way on the XO with it's
activity work flow model.   I also build ext file systems on USB keys to keep a
growing pile of pdf reference documents handy.  So far so good.




-- 
	T o m  M i t c h e l l 
	Found me a new hat, now what?