Jacek and friends,
Let's talk about disk characteristics.
Disk seek times have 2 components - head movement and rotational
latency. Using the most recent Seagate disk drives in our capacity
range of 500 GB or better, the average seek time for 7200 RPM disk
is spec'd by Seagate as 8.5 msec with a data transfer rate of 78
MBytes/sec.
The Maxtor 500 GB disk is also 7200 RPM drive with an average read time
of 8.5 ms. The data transfer rate of the interface is 'stated' as
300 MBytes/s
using SATA once the heads are finally over your data.
Disks have 4-8 surfaces with a head/surface. The heads are on one
head assembly and move as a single unit.
But these specs for individual drives are essentially meaningless.
We will use an integrated storage subsystem controller that implements
the file system as a wide striped RAID in a 8+1+1 configuration.
Since the drives are not synchronous, the average rotational latency is
not 1/2 of the period but 1/16 of the period - this is the time
before you
get *some* of your data.
Another result of the asynchronous disks is the subsystem controller
will
command each drive to seek as soon as possible. Again, this gives you
earlier read access to *some* of the data. The controller manages
its own
cache of multi-gigabyte capacity. It also does intelligent data
streaming which
you can think of as cache-prefetching.
The controller will re-order the disk reads it receives from all of
the host
processes to optimize overall seek time. The DB will be running
multiple
threads, right? The intelligent data streaming and command re-ordering
are going to be our big performance wins.
Finally, we will set the file system block allocation parameter and
other
knobs inside the controller to optimize performance for the 'typical'
DB IO.
I can buy today 1 petabyte of disk in an 8+2 configuration with a
peak 10GByte/s transfer rate. This is done with 1,920 disks of 750 GByte
capacity. The required floor space is 4 racks. You can scale this to
1.6 PBytes => 3,072 disks.
In 2011, the sustainable data transfer rate is closer to 30 GByte/s and
the integrated subsystem cost is 1/2 of today's price.
--Don
On Jul 6, 2006, at 1:09 PM, Jacek Becla wrote:
Hello,
One important knob that can significantly change database
disk IO is disk seek time. The disk model sent by Jim Gray
suggested 4 msec seek time and transfer rate 250 MB/sec, and
that is what I was using for estimating disk IO so far.
Our local (SLAC) hardware experts tell me 4 msec is optimistic,
and 6 msec would probably be more realistic (and it is unlikely
to change any time soon). The transfer rate on the other hand
is likely to go up because of the density growth. Unfortunately
this does not seem to help much for the page sizes we consider
(~128-256KB). The seek time change dominates, e.g. if I change
seek time from 4 to 6 msec and triple the transfer rate,
required number of disks increases almost proportionally to
seek time increase (e.g. from from 6K to 9K).
So I think I will need a bit of guidance from TechAssessWG regarding
what disk seek time I should assume for LSST for the year 2013.
For convenience I'm attaching the disk model provided by Jim.
thanks,
Jacek
<diskModel.xls>
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
