[MUSIC PLAYING]
Thanks a lot for coming and watching this tape.
I'm going to talk about input/output.
Now, input/output is an area that's
been an orphan of computer architecture long neglected.
So I'm going to need to motivate why you want to stay and watch
this tape.
To give you an idea of how much this area has been neglected,
first of all, the whole equipment
is referred to as peripherals, as opposed
to the central processor.
And secondly, there was a programming language that
was the ancestor of most of the programming languages people
use today, this program is called ALGOL 60.
And when was it was invented, it didn't
have any input or output at all in language and nobody cared.
So let me motivate why you want to watch this tape, starting
off with our first slide.
What's happening is a renaissance in CPU performance
improving by 50% to 100% per year.
In fact, what we have today is the supercomputer
in the desktop.
It's something that people have been
talking about for a long time.
What you see on the left-hand part of this slide
is the HP 735 workstation and the various characteristics
of that.
In contrast, on the right-hand side
is the Cray 1 supercomputer, the original vector supercomputer
and its characteristics.
When you line these characteristics up
by all measures, the HP 735 is faster or better
than the Cray Vector supercomputer, even including
the cost at about 1% or half a percent.
Another way of saying that is that the HP 735,
if it was announced in the late 1970s,
would have been a hell of a good supercomputer.
So we've got the supercomputer on the disk.
What an amazing development.
Moreover, people are taking tens or hundreds of these processors
and putting them together to create supercomputers out
of lots of these processors.
So that is moving at an even faster rate,
say, 150% per year.
So why do we care about I/O?
Well, because I/O hasn't been moving as fast
as the processor design.
It's limited by mechanical delays
and has been growing maybe 5% or 10%
per year over that same time period.
What's going to happen if we don't improve the I/O
component?
Gene Amdahl came up with Amdahl's law
that says system speed is limited by the slowest part.
So let's do a specific example.
If we spend 10% of our time today in I/O,
and we get a 10 times faster CPU, which comes along pretty
quickly, we're only going to get half of that performance
potential.
We're going to lose 50% of that performance.
Similarly, if we take that same program with 10% of its time
today and get 100 times faster CPU, possibly
with a multiple processor, we're going to lose 90% of that,
getting only 1/10 of its potential.
That means we have an I/O bottleneck facing us
very shortly.
Because a diminishing fraction of the time
is going to be spent in the CPU in the future
if we don't do anything about I/O.
That means a diminishing value of faster CPUs, which
means a diminishing value of researchers
who are working on CPUs, not to mention a diminishing value
of high-paid academic consultants on CPUs.
So I think we all agree this is pretty important,
even if we're not going to work on I/O ourselves.
So what have our colleagues in magnetic disk design been
doing all these years while we've been making processors
faster?
They've been concentrating on capacity and dollars
per megabyte.
They are improving at about 25% per year
historically, and more recently, at about 50% per year--
both of those measures.
The other thing that they've been doing
is evolving to smaller disks, from things
that were the size of washing machines or refrigerators,
to the things that you can fit in your hand.
Here's a specific example.
So this I have in my hand is a 2 and 1/2 inch diameter disk.
You can see it's very thin, maybe a 1/2 inch diameter.
And what's on the back of it is the electronics--
all the integrated circuits.
This disk, in the time we're making this tape,
can hold 320 megabytes.
As you can see, there's just two platters here.
This is remarkable shrinkage in design.
That's what our disk colleagues have been doing-- making things
smaller, the cost cheaper, and the capacity greater.
That's what they've been doing.
And in fact, in a few years, this
is going to seem like a dinosaur monster disk,
and people are working on disks that'll be 1 inch in diameter,
much smaller than a 2 inch, and you won't even
be able to know whether I've got one in my hand or not.
What our colleagues in the disk industry have been doing
is making disks that are smaller and cheaper, as opposed
to larger and faster.
The faster processors need larger and faster disks.
So the question we asked ourselves six or seven years
ago was, can these smaller disk be used somehow
to close the gap in performance between disk and CPUs?
Or how could we use these smaller disks to do that?
So the idea is to replace a small number of large disks
with a large number of small disks.
This next slide shows how it would work.
What we'd see on the top is the way
disks are traditionally manufactured.
What you see is four different designs
having four different engineering
teams, each concentrating on the high end
to the low end of the efforts.
What we're talking about instead is concentrating
the engineering talents in the lowest smallest diameter disk,
build the best disk you can, and simply
replicating to get mid-range and then high-end designs.
That's the El Dorado of disk array design here.
That's what people are trying to do.
Well, how well would that work?
What's shown on the left column is the IBM mainframe disk.
Back when IBM made a lot of money,
this is where a lot of money was made, in the mainframe disk.
If we contrast that with this narrower disk
also from IBM, which is in the middle column,
we can see some big differences there.
But if we got enough of those small disks, in this case, 70,
so that we would get the same capacity-- that's
this right column, it's the same capacity--
we have some interesting characteristics.
First of all, it's actually got some advantages
in size and power.
But the really exciting advantage
from the system designer's perspective,
given this CPU performance gap, is
the data rate or I/O rate-- data rate
megabytes per second transferred,
or the number of I/Os per second.
Given that we have 70 disks with 70 arms operating
at the same time instead of just a small number,
we can get a much higher data rate.
You can see that's about a factor of 8 improvement.
Even though the big disks run much faster,
we've got so many small ones that
are close enough we get a factor of 8 improvement,
and the number of I/Os per second,
similarly, increase by about a factor of 6.
And let's say the cost is about the same.
But what about this last row here?
What about the reliability?
This is an acronym for the mean time to data law.
So we can think of it as the mean time between failures.
How well will that work?
Well, turns out if things fail randomly,
then the reliability of N things is 1 over N.
So we take the mean time between failure
from about 50,000 hours divided by 70, 700 hours.
In other words, the mean time between failure
drops from six years to one month.
Therefore, disk arrays are too unreliable to be useful.
Therefore, it's a bad idea.
And this is the end of the tape.
Thank you very much.
No.
Don't-- hold that dial.
What we're going to do is add extra disks
and turns a weakness into a strength.
Hence, the name of RAID.
What we're going to do is take redundant arrays
of inexpensive disks by having some extras to overcome
this reliability disadvantage.
Now, there's two advantages here.
One is subtle and one's obvious.
What we're going to do have extra disks
so that when a disk fails, we can reconstruct the lost data.
That's the first point.
But if we can reconstruct the data sometimes,
that means that on the fly we can reconstruct
the data that's been lost.
So just because at the end of the term when everything's busy
a disk crashes doesn't mean you can't get your term paper.
Because it can be reconstructed--
it's going to run a little slower--
but reconstructed on the fly and given back to you.
We'll see a tape of that later, a demo showing it
runs a little slower, but the information's
available continuously.
And that's the basic idea of RAID of-- so this redundancy.
Now, it turns out there's lots of ways to do this redundancy.
What I'm going to do is cover four of them here.
What's shown on the left-hand side
is kind of the English descriptions of these things.
What's shown on the right-hand side is the levels of the RAID.
This was in our original paper.
We used these levels to explain things.
And as you can see, from top to bottom,
they're getting more sophisticated.
And these level numbers have caught on, probably
to the regret of some English teachers.
You may see these levels--
these numbers here that are put together
to describe advertisements.
You'll see level 5 RAIDs or RAID 5s and things like that.
What I'm going to do is go over each of these organizations
in this next part of the tape, and explain the advantages.
And basically, as we go down the line,
we're going to have less and less overhead
to provide redundancy to get that reliability.
The first organization is called either mirroring or shadowing,
depending where your--
what manufacturer sells it to you.
So what's shown on the left is the data disk.
And all these examples will have, say, eight data disks.
Now, what you need to do is to have reliability using
the mirroring scheme is every disk has its own mirror,
so that if you write to this disk,
you also write to the mirror.
That way if this disk fails, we know
where to go look to find the data that's missing.
This is the organization that's the favorite organization
of disk manufacturers.
The reason is that you have to buy twice as many disks.
Unfortunately, for those of us on a university budget,
getting extra reliability by buying twice as much disks
isn't something we could afford, so this wasn't something
we were interested in.
The next organization, again, has eight data disks,
and we've cut the redundancy down to four.
If you've taken a course in memory design,
you've heard about error correction codes
that can correct single errors.
You know there's a way to do this
without doubling the memory.
And in fact, what happens is is you
have, in this case, four redundant disks, and parity
is calculated over subsets of the data disk.
And you can see how this works in this example.
Let's suppose disk 11 breaks right here.
What would happen if we calculated the parities
in the subset is we get a 1 for this group,
because disk 11's included.
Disk 11 is not there, so that's a 0.
In this group, disk 11 is included, so we get a 1 there,
and this group would have a 1.
So we'd have the pattern 1, 0, 1, 1.
The fact that this pattern is not zeros
means there's an error.
And not only that, we need to figure out
which disk is the error.
And if you remember, if you're binary here,
1, 0, 1, 1-- if you convert that into decimal, that's 11.
So in fact, kind of as a parlor trick.
The encoding that shows [INAUDIBLE] here
also points out the disk that has failed.
So there is an error, and it's disk 11.
Now we've reduce the cost, in this case, from eight disks
to four disks, but that still would expensive
on the university budget.
The next scheme, RAID level 3, or redundancy via parity,
recognizes one of the really great things about disks today,
in that disks are smart.
Disks have controllers that know if they're working or not.
Moreover, on every single sector--
that's kind of every block that you can read or write
individually-- it has extra error-checking codes
to determine with very high probability
whether or not what you read was read correctly,
or if you write it, it's likely to be read correctly
again later.
Since there's the ability to determine
if a disk has failed--
the disk will raise its hand if it failed-- alls we have to do
is calculate the data that's missing from that disk,
and we can do that with one extra disk.
So this is the type of thing that's
interesting in a university budget.
So how does that work?
You can think of this disk as having
the sum of all the information on all the other disks.
Then if this disk fails, we'll know
that from the Reed/Solomon codes, alls we have to do
is subtract the remaining information from the sum disk,
and that difference must have been that value there.
That's what happens.
Actually, we do this all parity calculations,
but you can think of it that way.
So this seems pretty interesting.
Instead of having twice as many disks, we have one extra disk.
We can afford that on a university budget.
Now, so how well will this work?
So far you've probably been thinking of this as we write
a bit to every single one of the disks, so that there's--
a read will read from all nine disks in this case,
and a write will write to all nine disks in this case.
That's probably a good way to think of it.
You can think of this when they're
accessing all the disks as large accesses,
large reads and large writes.
If you think about this a little longer,
you realize though if every single disk has this error
correction information in each sector,
that would allow these disks to be accessed independently
with blocks that don't have anything to do with each other.
So if what we write to each one is a whole sector
at a time, or even a larger unit,
then we can let reads happen independently.
This would allow us to increase the number of I/Os
per second in terms of reads from this information.
So we could have the large reads that involve all the disks,
the large writes that involve all the disks,
and small reads without really any extra work.
That brings us to small writes.
What would happen if we wanted to write just to this one disk?
What it would seem like you want to do
if you wanted to write to this disk, what you'd have to do
is read all the information from the corresponding disks,
calculate the new parity and write that out.
Well, that's one way you could do it.
But because it's got this sum and difference relationship,
the other way we could do it is say,
let's compare the new data to the old data,
see which bits change, and then change
those bits in the parity disk.
Thus, a small write could involve
only two disks-- the parity disk and the disk with the data.
So that seems better than this other way
that involved all the disks.
So we can do the large reads-- everybody supplies disks;
large writes-- everybody gets some bits.
The small reads, which allow things independently,
and the writes--
unfortunately, the writes take four disk accesses--
reading and writing that disk, and reading and writing
the parity disk.
Moreover, what the problem is, the parity disk
is going to be the write bottleneck.
Every write has to update the parity disk.
Therefore, the speed is going to be
limited by how fast the parity disk can write.
This inspired the next organization.
Now, this is a different diagram,
with the disk in the top being shown in exploded form going
down the page, where each one of these squares
is supposed to represent a block.
You can think of that as a sector for right now.
So let's try this idea.
You notice what we've done is taken
all the parity, which before was always on one block
and spread it out.
We've rotated the parity.
So the parity for this first row, which
we refer to as a strike, this first row is here,
and then it moves its way down.
So how will small writes work in this case?
Suppose we're going to write to D3.
Well, we're going to have to update the block in D3, which
ties up this disk; update the parity right here, which
corresponds to the D3 which occupies this disk.
So we have two of the five disks occupied.
If the other disk we wanted to occupy, wanted to update,
the data we wanted to update was disk eight,
we'd also occupy this parity block.
So that would occupy these two disks.
Thus, without any really extra work, just by rotating
the parity, we're capable of getting
more small write bandwidth, which makes it more attractive.
This final organization, redundancy with rotated parody,
or RAID level 5, is the end of our progress
in getting performance and providing redundancy.
And this is the scheme that we used at Berkeley
and is very popular today.
You can even read articles in Byte magazine,
amazingly enough, at least when we make this tape,
and you'll see RAID 5, and now you know what that means.
OK.
Now in addition to coming up with these ideas,
we actually like trying to think about building these things.
And how are disks constructed today?
Well, the way disks work today is you don't just
plug the disk into a computer.
It's connected to a cable.
It's typically called a string.
And you put several disks on this string that's
connected to a string controller that, in this case,
would be connected to an array controller, let's say.
But the idea here is disks are connected over a set of wires
to a computer, and that's the way
things are done in many kinds of computer systems.
It would seem what you would do is just
put that stripe right down this row along this cable.
What's wrong with that?
The problem is now we have the string controller, a piece
of electronics which can break.
If this string were to break, that
would disconnect all of these disks from the computer system.
Now, this RAID thing works, provided
we only have one broken disk.
We can reconstruct it.
But all of the information in this group
would be disconnected.
That would mean we couldn't reconstruct that information.
However, if we do it orthogonal, if we change it
so that the disks are perpendicular to the strings,
what happens if we lose a string?
If this string goes out, we only lose one disk
from each one of the stripes, which allows us to reconstruct
that in the RAID project because that's
the way the system works.
If we lose one just from this [INAUDIBLE],,
it can reconstruct the lost information.
So just not, again, extra hardware just
by thinking about the right way you organize it,
you can get a more comfortable system, a more reliable system.
Another question that we asked ourselves
is what about spare disks?
What would happen if we were to have
some disks without any data on them
ready to repair in case something broke?
Right now you've been assuming that the disk breaks
and you call up your local system manager,
and he or she gets in their car and drives to RadioShack,
I guess, and buys a disk and bring it back,
and that might take a long while.
What happens if there's a spare just
sitting there ready to be used?
What this actually shows is the mean time to data loss.
That's like the mean time to failure.
How many, in this case, in thousands of hours,
before it would break?
Well, the study that was done here, assuming disks
fail independently, if we had--
assuming we started off with 70 disks,
with just one spare disk we would get this factor of 40
improvement in reliability--
40 times as reliable.
Interestingly, with two spare disks,
we're about as good as an infinite number of spare disks.
So this data suggests one or two spare disks
would really be an interesting thing
to consider in terms of improving the reliability
of RAID systems.
But at the top of the slide, it says
we're assuming independent failures.
We know disks don't fail independently
because of those strings that connect the disks together.
That's what this next slide shows.
So what would happen with dependent failures
because we disk are connected on strings?
Well, what happens is the relationship is changed to now
we need a whole spare string.
In this case, we are assuming that a string contains
seven disks on them.
So here's the disk across the bottom.
And these lines indicate one string full of disks
or two strings full of disks.
So now if we have a whole spare string because the string
controller could fail and knock out all of these disks,
we get a 50 times improvement in the mean time between failures.
But two strings was as good as an infinite number of strings.
So you can argue that one, possibly two spare strings
would be a good idea if you had about 70 disks in terms
of improving the reliability.
Well, not only do we try and come up with organizations
and thinking about building things,
we actually try and do this in a research context
that involves multiple disciplines.
So the project that I've been talking about, the RAID effort,
was led by Professor Randy Katz and myself.
But the context that we did this research
included network operating system
and file system work by John Ousterhaut,
particularly his Sprite project, a Unix-like operating system
with many interesting features.
At the same time also, Mike Stonebraker,
in the database processing-- transaction processing area
led the Postgres effort, his follow-on to Ingres.
So this work was being done in this triumvirate
of hardware operating system and database research.
The reason I really like this style of multidisciplinary work
is what's happens and shown on the next slide.
So Garth Gibson, who's now an assistant professor at Carnegie
Mellon University, Randy Katz and I
did the papers where we talked about the advantages of RAID,
but it has this drawback of these small rights being slow,
that which I talked about earlier.
Well, this inspired the operating system people,
in particularly, Mendel Rosenblum, who's
an assistant professor at Stanford University,
and John Ousterhout to start thinking
about what would a file system be like that
didn't do small writes?
They came up with the idea of making
the writes go as fast as the disk could accept them.
And so instead of doing accesses,
it's just writing without moving the head.
So it writes a stream or a log of the updates
rather than updating in place.
This is the log-structured file system
which is a pretty popular concept today.
This, in turn, inspired Margo Seltzer,
who is now an assistant professor at Harvard
University, and Mike Stonebraker to think
about having transactions support
in the log-structured file system
and see how all that would work to make databases run well.
And so this symbiotic relationship of the hardware
advances inspiring operating system advances and databases,
again, makes the hardware look good.
So that's one of the reasons I like these efforts.
Also, it's really a wonderful environment for the students
involved because students are educating each other about what
the important issues are, leaving
the faculty out of that loop frequently, to their benefit,
I think--
the benefit of the students, maybe not the faculty.
So in addition to all those things-- producing students,
writing papers, thinking about a build-in,
we actually try and build some things.
The first one we called RAID the first,
and this was just an off-the-shelf system.
It's been operational for several years.
It's off-the-shelf at the now pretty old fashioned technology
at SUN-4/280, some interface cards,
and really old fashioned disks--
5 and 1/4 inch disks, and we had 10 gigabytes of storage.
But this was our testing ground of trying these RAID ideas out
and see what we could learn.
And what we decided the follow-on would be,
which we call RAID the second, was
going to try and actually explore
the idea of a diskless supercomputer.
The system is organized for high performance
by integrating the network and the disk systems.
This next slide gives you an idea what we're talking about.
Here's the server on the right.
Now, the server is really--
to my surprise, doesn't really care that much about the data.
Servers care about metadata.
But the servers which are typically built today
is really just a workstation without a monitor on it.
That memory system can be a bottleneck to the disk
and to the network.
So what we did instead is put memory on the I/O card
so that we could have a memory, and we
could design the number of megabytes
per second of bandwidth of that memory device
to connect the disk to the network.
We happened to use an Ultranet, a commercial gigabit
per second network over the standard HIPPI, which
is the standard high-speed buses to connect to these network
cards.
So the server dealt with the metadata.
These disks dealt with the data transfer themselves,
but the memory is the buffer between these two,
and then out over the network to the rest of the community.
This is what we call RAID the second.
What I'm going to do next is show a videotape of a demo.
And this demo in particular is going
to show what happens in terms of performance
by using graphics when a disk is to fail
and showing continuous update on the fly.
And then the actual daredevil demo,
where a disk is going to be removed from the live array.
And you'll see the data being reconstructed.
The person who giving this talk is
Ed Lee, one of the several graduate students working
on the project.
His portion of the demo was doing the live portion
of the reconstruction because he did the reconstruction
software.
And Lee's getting his PhD shortly
and going to join DEC at the Systems Research Center.
Here's the demo.
[VIDEO PLAYBACK]
- So as we mentioned before, our RAID [INAUDIBLE] server is
based upon a RAID level 5 disk array,
which means that given in the event of a disk failure,
we can continue supplying data uninterrupted to our clients.
And also, we can dynamically rebuild the contents
of the failed disk onto a spare disk
without interrupting the flow of data to our client.
So in this demo, there will be three primary parts.
The first part, we will cause a disk to be failed.
In the second part, we will rebuild
the contents of the failed disk onto a spare disk.
And in the third part, I will actually physically remove
a disk that is in--
that is configured into the system.
And in all three phases, you'll see
that there is no interruption of data to our clients.
So for the first part, we go back to our video display here.
When we start initially fail a disk,
you'll see that there will be a brief pause while the RAID disk
array reconfigures itself, [INAUDIBLE] the pause there,
but now is continuing to display the frames at approximately
it's normal rate.
If we go over to the performance monitor,
you see that at the point at which the disk failed,
there is a slight spike in CPU utilization caused
by the extra overhead and rearranging certain components
of the RAID driver.
And afterwards, you see that the utilization is slightly higher
due to the extra work required to reconstruct
the contents of the failed disk as it
is requested by the client.
Now we'll start the rebuild process.
And now the contents of the failed disk
is being rebuilt onto a [INAUDIBLE]..
And you see that the CPU utilization
has increased significantly.
And this is due to--
by approximately 20%.
And this is due to all the additional I/Os required
to rebuild the contents of that failed disk.
We know that the number of the disk I/O's reads and writes
have not changed significantly.
And this is because this performance monitor measured
logical I/O that is performed through the disk array rather
than the physical disk activity.
So now the rebuild phase is in [INAUDIBLE]..
And you see that the CPU utilization
is returning to its approximately normal rate.
And during that entire period, the supply
of data for our clients was not interrupted.
And the clients continued to display the images
at approximately their former rates.
OK, so for the final more dramatic portion of our demo,
I will actually physically remove
a disk which is currently configured
and running in the RAID server.
And you'll see that even in that case,
RAID-II can provide the necessary data to its clients.
Here, I am about to remove the disk.
Now I actually physically remove the disk.
As we go back to our monitor, you
see that the client is still getting its necessary stream
of data, and it's still running at approximately
its original frame rate.
This shows that the dynamic reconstruction of data
is working properly.
So that concludes the RAID demonstration.
We'd like for you to keep in mind
that many of the bottlenecks that we've illustrated today
has been due to either our limitations
on the client or the disk controller.
So as we appropriate faster clients and disk controllers,
we would expect performance to scale appropriately.
So thank you for watching.
[END PLAYBACK]
So one of the questions was, well,
just how well does all these redundancy schemes work?
Remember, we're going to take this weakness
and turn it into strength.
How big a strength is it?
And you can see that on this next slide.
Everything's the same as the earlier slide.
We're going to have a few more disks there
to find the reliability if the cost is a little higher,
but we can say the cost is about the same.
But the big change is the mean time to data loss.
By having this many extra disks, we
can take this weakness, remember,
that was down to about a month of reliability, and instead,
turns it into a tremendous strength--
a ridiculous calculation of ours.
So what we wanted to do is make it
as reliable or more reliable than a mainframe disk,
and we can do that.
In addition to doing these ideas,
let's talk about the future of this.
In a few years, we're going to have these one-inch disks.
And you can imagine on a single notebook-sized computer having
32 of 1-inch diameter disks provide you,
say, 8 gigabytes of storage, more than 100 megabits
per second transfer rate, and very, very high reliability.
In addition to producing students, writing papers,
giving talks, making videotapes, we also
like to transfer the technology to companies to use it.
There is even today amazingly a RAID newsletter
to keep people up to date on what's happening in RAID.
And I think there is-- it says 100, but maybe even 200
companies involved in RAID systems are selling components.
Several of the major companies you'd recognize there
are selling them right now, and other companies
are developing RAID systems.
At the bottom, I mention the IBM story.
One of the companies there, Storage Technologies,
decided to talk about their product, a very complicated
product, that not only does the RAID ideas,
but does compression and other things on the fly, which--
and their code name for it was the Iceberg Project.
Well, they went around and gave 700
non-disclosure presentations on Iceberg.
So those of you who can imagine with human nature
realize that 700 nondisclosures is an oxymoron.
This is really obviously-- well, not obviously,
unfortunately, even though they swore they wouldn't, they
started talking about them.
So IBM salesmen heard a lot about RAID.
And so I was told shortly after that
that IBM salesmen were going around saying
RAID was a bad idea.
So I knew this was a really good sign.
If IBM salesmen are marketing against a research idea,
something must be going on.
And in fact, today, as I said, you
can read about it in Byte magazine.
And IBM, their president of their disk company
has said that RAID is just like a fine wine.
They won't deliver it before it's time.
And when RAID's ready to go, IBM will be there.
And that's the way they wanted to go with their mainframe.
They already are developing an offering
for sale RAID systems in other markets,
particularly their supercomputer kind of markets.
But eventually, the expectations are that IBM will switch over
to RAID for their big systems.
So that's kind of the end of the RAIDs
part of this presentation.
And this is--
I've used past tense a lot because this
is all done and all wrapped up.
Just about everybody is going to be graduating soon
from Berkeley, and people are using the ideas.
What I'm going to talk about next
is stuff that we're working on now
and tend to work on the future, and it's to be more futuristic.
There's three pieces of this part.
And we liked working on I/O so much
we decided we'd keep working on it.
In fact, if it was good to work on secondary storage of disks,
well, tertiary storage must be wonderful.
And that's what we're working on today.
And if you can think as the small disk
is what inspired us to work on the disks today--
remember these small disks.
What can we do with these things?
I think what's inspiring this research project
today are these tapes.
This is a tape that's right of your camcorder camera,
and this tape can hold, amazingly
enough, 5 gigabytes of information.
Putting that in perspective, that's like 5,000 books.
That's how much can be in this tape.
This tape costs $10 to $20.
I can hold it in my hand.
So the question that we ask ourself, gee,
with a tape like this, how could a computer system designer
use that and put it to use?
And that's, I think, this tape is
what's inspiring for the next part of our research effort.
So there's three parts of this technology.
It's these helical scan tapes, which
I'll talk more what helical scan means shortly;
tape robots that can hold lots of these tapes
and make them automatically available;
and then data compression.
And that's-- I'll be spending the rest of this tape talking
about these technologies, then talking about the applications
of these technologies.
But try and remember, you can't see my arms
waving the whole time, but my arms
are waving the whole time I'm talking.
Because this is what we're going to do rather than something
we've already done.
So what's all this about tape?
If I've been chairman at Berkeley for a while,
and I go into some rooms and I'll
see these rooms full of magnetic tapes.
So pretty much what I've determined
is tapes so far have been written once
and read zero or one time.
People do these backups of tremendous amounts
of information, and I'll try and reclaim storage space.
And oh, no, no.
You can't get rid of that, that 1985 tape.
Somebody may ask for that file some day.
Now, I don't think very many people
ask for 1985 tapes in this day and age,
but we've got these roomful of these tapes.
And they also get used for distributing software.
What I'm talking about, using tapes very differently,
using them like you use disks, reading them and writing them,
making them automatically available for people to use.
And that's what the new opportunity is.
So that's a fundamental relationship
between tapes and disks.
And longitudinal tapes actually use the same technology
as hard disks.
And they're going to track each other's improvement.
So the media itself is pretty similar.
The differences are inherent in the geometries.
Disks-- remember, I showed you before-- has platters
and randomly rotating with these gaps for these arms
to move in and out gives them the random access.
Because these arms are flying so close to all these platters,
they have to seal it so the drive and the media
are a single unit.
In contrast, tapes are this magnetic information spread
on these removable strips that are on a spool.
There's sequential access, no random access.
But because of the nature of the way the readers work,
you can insert and remove these tapes
so you can have many tapes to a reader.
And so it's got these fundamental advantages
as a random access versus sequential access,
and multiple media per reader versus one media per reader.
So I expect 20 years from now, we'll
still have these kind of relationships in these two.
But there's this new technology, which I showed you earlier,
called helical scan.
So what helical scan does is different
than the longitudinal tapes.
Longitude tapes, the information is across the tape as it moves.
So helical scan is the tape is spinning,
it has the head at an angle to the tape,
and it's spinning very, very rapidly,
so as the tape moves by, it can record lots of information.
So you can get factors of almost 100 increase
in the density of the tapes with this new helical scan
technology.
Now, as you can see on the slide,
this is not some exotic technology that's unavailable.
This is pretty standard technology
that's being used in every VCR, in every camcorder.
And if you happen to have a digital audio tape stereo,
it's being used in that technology as well.
Now, you would think that there's,
given the sequential nature, it would
be very slow, which is true.
It is pretty slow, especially compared to disks.
But because they keep a longitudinal track,
they have a fast search mode.
So actually, here's three different--
these three different columns are
examples of different kinds of helical scan technology.
Random searches will take tens of seconds,
where you might think they might take
several minutes because they have fast search mode here.
This shows the density of these tapes-- this one at about--
this is in megabytes, so this is almost 5 gigabytes here.
Here's a couple of other ones that are going on.
And this compares it to magnetic disks in the conventional tape.
And you can see comparing conventional tape,
a dramatic difference in the density of these technologies.
Now usually when I give a talk, and there's
people who can talk back, they-- somebody raises their hand
and asks, what about optical disk?
Optical disk is a very interesting technology,
especially if you're going to make one copy of things
and want to stamp it out for [INAUDIBLE] many people
dramatically inexpensively.
For a couple of dollars, 1 gigabyte of information
can be stamped out repeatedly and used at many places.
But if we compare the media cost to these 8 millimeter
tapes, the helical scan tapes, you
see there's a very large difference, so that basically
there's almost a factor of 100 difference in terms
of the media in terms of dollars per megabyte
of helical scan versus the optical disk.
Optical disks are moving more or less at the rate
the standards committees can agree on standards,
while the helical scan tapes tend
to be pushing the technology.
Now, there's some-- so it's got that advantage,
the helical scan tape, and that's
what's, again, waving our hands is where we are today
at Berkeley and pushing the helical scan tapes.
But we've learned a few things that are
disadvantages of these tapes.
First of all, they wear out.
Helical scan devices, because they move very rapidly
over that tape, the tape can wear out more quickly.
Even longitudinal tapes can only have thousands of passes.
Moreover, the heads wear out as well.
So that's some disadvantages of that technology.
So your economic model has to factor in the advantage
of helical scan tapes.
You have to subtract out the fact that the tapes wear out
and the heads wear out.
But there's still, when you have a factor of 100 advantage,
that's a serious advantage.
Also, right now, if you looked at the tapes the way they work,
there's this very long rewind, eject, load, and spin-up times.
But I believe that's not inherent.
It's just there's no market yet for somebody
using these tapes in this unconventional way,
as if they were disks.
If that was important, I believe engineers could design them
that they wouldn't be so slow in terms of loading and rewinding.
Now, that's the tapes themselves.
What about the tape robots, the second piece
of this technology?
If you were able to see this setup that we
have in this room, we could fit on the same stage
where I'm talking a 10 foot by 8 foot monster called the Storage
Technologies 4400.
This robot, which isn't that big, and at a half
million dollars isn't really that expensive,
could hold 6,000 tapes.
In 1992, that would be about 5 terabytes.
Next year they're going to make the transition
from longitudinal to helical scan,
so that same robot could hold 120 terabytes.
When we start talking about numbers like this
it's hard to keep track of what we're talking about.
It's like talking about the national debt.
A trillion dollars-- how much is a trillion dollars?
An extra trillion dollars-- is that bad?
What does it mean?
Well, terabytes-- 120 terabytes is a fantastic amount
of information.
If we were to go to the Library of Congress
and see their attempt to capture the sum of humankind's
knowledge, to give you an idea of how aggressive they are
in getting information, 2/3 of their holdings
are not even in English.
They're trying to get everything that's been printed
and keep it at the Library of Congress.
If we could magically transform all the texts and all
of those books and put it onto a computer,
it's been estimated that's about 20 terabytes.
So with 120 terabytes, we could have six copies
of all of humankind's knowledge right up here
on the stage next to me for about a half a million.
So this is an extraordinary amount of information.
So the tape robots which are available right now
give us this automatic access, still with a long access time.
Now, those of you who've been in the industry
for a while would seem-- even this is--
seems like this is infinite amount of information.
But you know when dealing with programmers that they always
complain.
So this can't be enough.
So we have to get even more than this,
and that leads to the next topic of data compression.
So compression has some simple terms, easy to figure out.
The first one is a style of compression called lossless,
and that gives you typically factors of 2 or 3.
And your contract is you won't lose any bits,
but it will take one half to one third the space.
And text is typically done with compression.
The second category called lossy allows
you to lose some bits as long as it still
looks good to the visual--
to the human eye, visually interesting.
So these are images.
And sometimes they get factors of 20,
sometimes less, sometimes much more than that.
So the question as computer systems designers
with this new technology is, where
is compression going to be used, and where should it be used?
So this complicated line drawing here,
let me go show you how that works.
Here's the tape itself.
Here is its controller.
It's connected over a cable, a SCSI cable
to the SCSI host bus adapter.
SCSI is one of those cables that connect peripherals
to computers through a file server over a long haul
network, to another file server over a local area network,
to the processor and memory, and it shows up on the screen.
So where is it being used today?
Well, the compression is being used right now
in the controller.
And in fact, you have to be pretty careful
when you buy either a tape controller or a disk
to find out whether or not when they
argue the capacity of this tape or the disk,
whether they're counting on compression.
So the same tape may hold 5 gigabytes,
but it maybe advertised as a 10 gigabyte or 15 gigabyte tape,
because they're counting on getting this factor 2 or 3
with lossless compression.
So you have to--
user beware here, buyer beware.
From a computer systems perspective,
what do we think of that?
Well, what we think is that's the stupidest place
you could possibly do it.
Because after you get that data and you decompress it,
then you have to ship that larger piece of information
by factors of 2 or 3 over each one of these cables,
all the way until just before it gets to the screen.
Therefore, you get the compression advantage
of the tape, but you don't get any benefit.
And all of these wires, you have to pay extra,
or it takes longer to transfer them to get there.
What we really want is just-in-time decompression.
What we want is keep it in the compressed form,
send it all the way around, and just
before it pops up in the screen it gets depressed--
decompressed.
It may get depressed, too, but, it should get decompressed.
Now, there's advantages of that.
If we're up here, we know what kind of data it is.
And if it is an image, we can use image compression
and get even greater than factors of 2 or 3.
So this is the right place to do it
for a couple of different reasons.
Now, when we're talking about hundreds
of terabytes, what application would
we use at Berkeley to be able to drive this?
What we chose to use is this project
called Sequoia 2000, which is a global change research
effort involving Earth system scientists and computer
scientists.
These people are trying to worry about the problems facing
our planet.
They're worrying about CO2 content.
They're worrying about the melting of the snow caps.
They're worrying about the ozone holes.
These are the researchers that are
dealing with it, either with simulating data
or sensing data from space.
The project at Berkeley involves computer scientists
at several UC campuses, Earth system scientists at several UC
campuses, and even some people from the real world
who are trying to use this data to do public policy decisions.
These global change researchers are drowning in data.
They get all this data from remote sense
from satellite in space that they need to deal with today.
Modelers will typically create a tenth of a terabyte for a year.
In just a few years, they're going
to put up a series of satellites in space, that once they're
in place, they're going to broadcast 2 terabytes per day,
these bits raining down from space,
and they're going to keep broadcasting
that information for 15 years.
And what they want to do is capture all that information,
and so that it's digitally recorded so that they can
do simulations in the future to see
if their theories about the climate
bear up to this 15-year case study.
So this is really going to challenge
all levels of computer systems to be able to pull this off.
To give you an example of the type of thing we'd like to do,
I'm going to show you this next videotape as an example.
This is not something we've done.
This is the type of thing we'd like it
so that Earth's system scientists, global change
researchers, could try on their screen to find things out.
For this example, it's going to be
using green to represent the chlorophyll content of plants.
And what you're going to see is the trade winds blow the rain,
the chlorophyll will move across South America
and bumping into the Andes.
And this would show what would happen
if there was a environmental accident on the East
Coast of South America, how rapidly that might contaminate
the South American continent.
And you can see as it contraposes this information
according to altitudes, you get some interesting insights
to what's going on.
This is an example of something that we
would like to do in the Sequoia Project
and should fire your imagination.
Here's the demo.
[VIDEO PLAYBACK]
- So now let's compare North America with South America.
The relation of vegetation production
to global climatic patterns is clearly reflected here.
The tropical easterly winds spread rain
across the continent to make it green.
They drop the last of their moisture
when they meet the tall Andes mountains on the left.
The black area of low production on the left
reflects the dry lands and the rain shadow
produced by the Andes.
Why, then, is there another black shadow
in the lower portion of South America,
but on the opposite side of the Andes?
This occurs at exactly 30 degrees South latitude,
where the tropical easterly winds shift
to the westerly winds which characterize temperate zones.
GRAS is a system designed to support scientific research
and to answer land management questions.
This presentation suggests only a few
of GRAS's potential applications.
It does illustrate how today's technology can integrate
the latest satellite imagery, computer manipulation
techniques, and hardware capabilities
for visualizing our fragile ecosystem in ways
not previously possible.
[MUSIC PLAYING]
[END PLAYBACK]
That's one application of the technologies
to help the global change researchers,
but another interesting application
is the electronic library or digital library.
And you can see that on the next slide.
If you visit the Berkeley campus, one
of our nicest buildings on campus, the Bancroft Library,
that has just 372,000 books in it.
And if you convert that into text,
that'd be about half a terabyte.
If instead of just having the text, if what you had
was the images of the full page, that
might take maybe 20 terabytes.
That's not a very big piece of that storage robot
that we talked about earlier.
Moreover, if you visited the campus
right now while we're filming, we're
in the middle of a four-year, $45 million project
to create a building contain two million books.
Right now in the state of California, $45 million
is a lot of money.
And what we're doing is building this building for books.
How good an idea is that?
We could fit all that information,
even the page images, into one of these robots.
And it's pretty expensive to create this.
I wonder whether or not if you visit the Berkeley campus in 10
years and come on a tour guide, people
are going to refer to this new building as the mausoleum
of dead trees, Tien's folly, where they spent $45 million
to hold all these books.
And in fact, I've given this talk before
and talked about how libraries work
so much that I can see clearly in my future
how libraries are going to be so different from the way they are
today.
And when we look back at these times,
people are going to chuckle.
And to put that in perspective, let
me tell you what's happened in my lifetime
in terms of learning how to program,
and then we'll fast forward and talk about how libraries work.
So the way I learned to program is I would write my program out
on a sheet of paper.
I would then go to a vending machine,
put a quarter in the vending machine,
and get a stack of IBM cards.
I would then take my piece of paper,
wander over to the keypunch machine, and type
in, keypunch, put little holes in cardboard
all of those characters.
I would take this stack of cards,
wander over to somebody at the counter, smile,
try and get to know the person, be the best friend,
hoping that that stack of cards will get
put at the front of some queue.
Then what I did was go home, come back the next morning,
look, bend down, find my slot with my name,
and kick out a line printer listing to see what happened.
Ah, left out a comma.
Take the cards, go over, get some more cards,
replicate, insert the comma, hand it to the guy,
smile, come back the next day for the next printing
of the cards.
Now, that is the way I learned to program.
How do people learn to program today?
I'm not sure that students today even know
the syntax of the language.
They start typing, commas get inserted automatically
by the editor.
I can imagine-- suppose what we did on
the Berkeley campus would say, boy, things are tough.
We're having to build this library,
it's using up our funds.
So what we're going to do is go back and teach programming
the way the faculty learned how to program.
We would have a riot on the Berkeley campus
to put People's Park to shame.
They'd say, nobody can learn to program that way.
That's prehistoric, impossible.
Only an idiot would even suggest it.
So let's talk about libraries.
Imagine we fast forward about 10 years,
and let's explain to the people 10 years in the future
how we use libraries today.
So the way we use libraries today is if you're lucky,
and you've got electronic card catalog,
you can find what you want and you write down
the call letters.
Then you get up out of your office,
or you come from home to the campus, wander around,
and if you have a special pad, you're
allowed to get into the stacks, go up and down the stacks,
find the call letters, look where the book's supposed
to be in the shelf, and then you look all around
because it's probably not where it's supposed to be.
And if it's not there, you look over
to the cart that's right next to it, which
has the books that haven't been put away yet
and see if you can find it.
If you're lucky, you find the book you want.
You wander down the stacks, go to the hard disk.
If you're fortunate and you have a modern library,
they'll use a grocery scanner to scan it in.
If not, you have to write your name on this little card.
You take the book.
You go back to your office or go all the way home,
read the 10 or 20 pages you cared about, and then you try
and remember to take that book back,
because no one else gets to use that book while you're
having it.
And then when you do get that postcard in the mail
after three weeks or after the end of semester
to remind you to bring that book back, you bring it back,
and it gets put on the shelves.
So imagine telling somebody 10 years from now this is
how we did scholarly research.
This is how we found out what other people were doing.
They'll say, but you must never have read books.
You must not have taken any time at all to do that,
so it's so painful.
It must have taken you hours.
Yes, it took hours.
And it must have been very expensive.
Oh, it was very expensive.
Every time you check a book out of a library,
a library is doing a very good job
if it only cost them $1 to put the book back on the shelf.
So the best thing you could do to help libraries out right now
is to not check out any books.
That would save them a lot of money
if nobody checked out books.
Libraries also have to buy books in anticipation of their use.
So a librarian is doing an outstanding job if only
20% of the books that they buy on the Berkeley campus, that's
about a $3 million budget.
So 20% of the books that they buy, no one ever,
ever checks out.
Not once.
So that's just-- those books just sit there and use up
shelf space.
Similarly, to create a catalog entry for a book
costs a big fraction of the price of the book.
So the system we have today is extraordinarily expensive,
and it's extraordinarily inconvenient.
Imagine having to get up out of your chair and go do that.
You can imagine 10 years or so in the future,
people are going to be doing-- searching
for the right information, getting those 10 or 20
pages they're interested in pop up on their screen,
reading that, inserting what they need, and move ahead.
It'll be dramatically different than we do today,
as dramatically different as the way I learned
to program versus the way people are learning to program today.
In fact, I've given this talk enough
whenever I go to the library I get angry that I've
got to go through all this rigmarole
because I know it's not necessary.
The technology is there to do that.
So let's start wrapping this talk up here.
What I'm talking about in the second half
is a new technology.
This is a pretty classic curve that's
been shown for a long time where there's DRAM in magnetic disks.
And this has been called the access gap.
This is a log scale in terms of dollars per megabyte.
This is the most expensive.
This is the fastest down here-- log scale and access time.
So DRAM's expensive and fast.
And this is an access gap that a lot of people
have tried to invent technologies to fill.
What I'm telling you, there's going
to be a new access gap, this robo-line tape that
is much cheaper and much slower, and how do we
figure out how to use that as systems designers?
So there's lots of research issues we've got to attack.
And again, remember, I'm waving my hands
because it's things we need to do.
There's, how are we going to manage three or four levels
of storage hierarchy, when in the past
we've only managed two?
How are we going to manage that inherent latency
of this new technology that's very cheap?
Other examples of what are we going to do with compression?
Can we do it on the fly?
What about hardware?
How are we going to keep this reliable?
If you have sum of humankind's knowledge,
it's not OK if the sum of humankind's knowledge
goes down.
It's not OK if you lose Marc Twain's collected works.
And what does it mean to back up 100 terabytes?
So there's lots of interesting issues there.
So for my last slide, let me conclude with a prediction
that this new storage technology is going to really change
our society provided a couple of things,
that for a cost of a minicomputer,
if you can get a factor of 1,000,
that's a pretty big impact and that's going to change things.
The obstacles aren't technical, though, in my view.
The technical obstacles that come up I bet we can attack.
We've done it in the past.
First of all, it's the legal copyrights
that's going to be an obstacle.
I'm not allowed to make an online copy of all the books
on my library at home because the copyright says
that's a copy.
So copyright is an obstacle to online.
Similarly, business model is going to be an obstacle.
Paper-based publishers are used to having a book,
meaning they get money.
If they place that information online,
what guarantee do they have that they'll get any sales at all.
Why won't it just be copied?
So we have, as technologists, to provide those guarantees.
So my prediction by the end of this decade
before the next century, that if we can address the first two
non-technical issues, that this factor of 1,000
increase in online storage is going
to have a much greater impact in our society
than this factor of 1,000 increase in CPU speed.
So thanks very much for your attention.
You really did stick through and listen to the whole tape
about input/output.
But I hope you could see from this tape
just why input/output is so much more exciting in processor
design, and you'll agree that terabytes is a lot more
important than teraflops.
Thanks very much.
Yeah, where's the applause?
Yeah, where is the applause?
If this was on TV.
We could insert the laughter.
[LAUGHTER]