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

[Peter Jakobi]

On Fri, Dec 12, 2008 at 08:17:19AM -0600, Geoff Jacobs wrote:
Rehi,

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

if so thanx!!
Peter


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