[Beowulf] SSD prices - q: how many writes/erases???
Nifty Tom Mitchell
niftyompi at niftyegg.com
Wed Dec 17 16:31:24 PST 2008
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
> 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).
> 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 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 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?
More information about the Beowulf