Solid state disk: show me [LWN.net]

Solid state disk: show me

Posted Mar 27, 2008 6:24 UTC (Thu) by jwb (subscriber, #15467)
In reply to: Solid state disk: show me by flewellyn
Parent article: Predictive ELF bitmaps

They're also not very fast, especially when writing.  We're getting close, but we're not there
yet.

Relatedly, I recently noticed an annoying habit of web browsers on laptop computers.  When the
disk is stopped, it's normally much faster to fetch an item over HTTP than to read it from the
cache.  But popular web browsers insist on consulting the cache which, on my laptop, takes 1-2
seconds while the disk spins up.  An interesting lesson in the relative costs of fetching
data.

(Log in to post comments)

Solid state disk: show me

Posted Mar 27, 2008 6:36 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

Yes, that's probably because the browser caching behavior is still based on older assumptions
about network and disk speeds.  It made sense back when dialup was the norm.  In this era of
ubiquitous broadband, though...

Solid state disk: show me

Posted Mar 27, 2008 9:04 UTC (Thu) by pointwood (subscriber, #2814) [Link]

"They're also not very fast, especially when writing.  We're getting close, but we're not
there yet."

Yes, we are getting close. From what I read, we can look forward to 100MB/s writes in the very
near future. Furthermore, they scale really well:
http://www.nextlevelhardware.com/storage/battleship/

Solid state disk: show me

Posted Apr 18, 2008 18:31 UTC (Fri) by ranmachan (subscriber, #21283) [Link]

"Yes, we are getting close. From what I read, we can look forward to 100MB/s writes in the
very near future."

But is that for continuous writes or random writes?
The latter case matters more.  I replaced the hard disk in my notebook with a compact flash,
which can do 20MB/s continuous writes (which - while not exactly fast - would be more than
enough performance), but slows to a crawl (in the KB/s range) on random writes, especially
when cache flushes are involved (FS metadata updates, fsync&co take ages).

Solid state disk: show me

Posted Mar 27, 2008 11:37 UTC (Thu) by nix (subscriber, #2304) [Link]

You can avoid the not-fast problem by rsyncing /usr/bin and /usr/lib (and parts of
/usr/share?) into battery-backed/flash RAM, so most of the time very few writes would be
needed.

(Obviously rsync for this purpose is a kludge; some sort of replicated write at the kernel
level seems preferable. Perhaps dm mirroring could do this, but it'd be forced to replicate
all of /usr into flash, whether we care about it or not...)

Ramback

Posted Apr 1, 2008 18:36 UTC (Tue) by dmarti (subscriber, #11625) [Link]

Or do something like the "Ramback" patch from Daniel Phillips (LWN article): "The core idea behind Ramback is that all of that memory is turned into a ramdisk, but with a persistent device attached to it. In normal conditions, all application I/O involves only the ramdisk, and is, thus, quite fast."