Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
We actually have them now. Flash drives are ubiquitous, and a major system vendor (Apple)
recently put out a line of machines (Macbook Air) featuring solid-state disks.
Solid state disk: show me
Posted Mar 27, 2008 6:24 UTC (Thu) by jwb (guest, #15467)
They're also not very fast, especially when writing. We're getting close, but we're not there
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
Posted Mar 27, 2008 6:36 UTC (Thu) by flewellyn (subscriber, #5047)
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...
Posted Mar 27, 2008 9:04 UTC (Thu) by pointwood (guest, #2814)
"They're also not very fast, especially when writing. We're getting close, but we're not
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:
Posted Apr 18, 2008 18:31 UTC (Fri) by ranmachan (subscriber, #21283)
"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).
Posted Mar 27, 2008 11:37 UTC (Thu) by nix (subscriber, #2304)
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
(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...)
Posted Apr 1, 2008 18:36 UTC (Tue) by dmarti (subscriber, #11625)
Posted Mar 29, 2008 0:22 UTC (Sat) by giraffedata (subscriber, #1954)
And as in 1978, they are more expensive than moving-head disks. Even after you count the cost of the slowness and the engineering to avoid the seeks.
That's on average, of course. Solid state storage gets used more and more every year as more applications fall out of the disk-costs-less category.
I think one of the great pastimes in the computer industry these days is guessing when more than half of storage will be solid state. While non-professionals have been saying "a couple of years" for about 20 years, I'm now beginning to hear 5 years, for new storage, from credible professionals.
I know some day the use of moving parts in a computer will be a subject of ridicule. It already seems perverse.
Posted Mar 29, 2008 1:11 UTC (Sat) by nix (subscriber, #2304)
Clarke had it taking a million years in _The City and the Stars_. It seems
like we might manage the no-moving-parts dictum, in computers at least, a
good bit sooner than that.
(I definitely agree with that dictum: `no machine shall contain any moving
parts.' As a recipe for long-lived hardware, it has few equals.)
Posted Mar 29, 2008 2:00 UTC (Sat) by zlynx (subscriber, #2285)
Even with zero moving parts, thermal migration of the material on the silicon will limit the
life of a computer system.
Posted Mar 29, 2008 13:21 UTC (Sat) by nix (subscriber, #2304)
Yeah, but it's *better*. ;}
(now the fix-every-atom-in-place, fix-reality-to-a-virtual-backdrop tech
they had in Diaspar, *that* was advanced. And probably physically
impossible, but it feels like it should have worked. Ah, Clarke wrote some
good stuff in his day.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds