[Discuss] SSD

[jack at coats.org (Jack Coats)]

<War story>
In the '80s and '90s mainframes had storage, lots of it for the time.
There was consistantly a problem with how to best use 'fast storage'.

We found the best was
  1) RAM - as much of it as you can afford
  2) SSD - yes we had them then and they were expensive (and lost
storage when powered off, had to be reformatted at every startup)
                in production we used it ONLY for swapping and paging
( paging, moving single pages to/from virtual memory at once,
                   swapping moved multiple pages in and out at once)
                in testing, we played with putting 'hot' files on it
and it was GREAT for performance
  3) Drum - or disk but head per track, no moving heads, and the
faster it spun the better.
                Reduced access time effected overall system performance.
                Again used for paging and swapping
  4) Disk drives - we actuall had some we used for swap and page, but
for those drives, we used the 'center cylinders' and left the rest of
the pack un-allocated (I used the 'unused space' as a systems geek for
data I needed to keep but not access during prime work hours, so no
user data)
  5) Tape - yep, CDC 1604 paged off of 7 track, 256BPI 2400' tapes.
No disk available, 8 tape drives.  Tape operating system. ...
                I hated cleaning the tape drives that often! ...
Operating system, paging, programs, libraries, user data, everything
was on tape.  It 'booted' from a big stepping relay built with lots of
diodes buried in the console.  It had 64K of 48 bit words made from
core memory.  Most instructions were 'half word' but some were full
word and had to be 'word aligned'. - I never used the console paper
tape reader and punch, but the console was a IBM key-slinger
typewriter, and there was a speaker across the 'A' register used for
operator notification, alarms, warnings, or during play time for games
and music.  Fortran IV and Fortran 2 ran well, COBOL was available and
took what seemed like 'forever' to compile, but it ran OK.  Assembler
wasn't to bad, actually easier than the IBM 360 assembler to
understand and use, at least for me.
</war story>

In summary, speed of storage matters, and faster storage runs the
faster all computers run to get work done for the end user.  I like
Linux because it is set to automatically use all 'non-program' memory
for caching I/O, and throwing memory at todays machines almost always
seems to help.  That goes a long way for reducing I/O waits both on
read and write.

One old saw that needs to be updated, was
  if a processor accessed a register in 1 second
  it would access processor cache in 5 seconds
  it would access main memory in 30 seconds
  it would access disk drives in 30 minutes
  it would access tape data in 4 weeks

Those are from memory but you get the hint.  Someone want to update
that for todays processors, try using
  register, memory, ssd, hard drive, SAN or iscsi, networked drive (cloud?)

It is pretty eye opening for where you really want to put your data.