Upload
kellan
View
50
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Chapter 7 Storage Systems. Outline. Introduction Types of Storage Devices RAID: Redundant Arrays of Inexpensive Disks Errors and Failures in Real Systems Benchmarks of Storage Performance and Availability Design An I/O System. Introduction. Motivation: Who Cares About I/O?. - PowerPoint PPT Presentation
Citation preview
1
Chapter 7 Storage Systems
2
Outline
• Introduction• Types of Storage Devices• RAID: Redundant Arrays of Inexpensive Disks• Errors and Failures in Real Systems• Benchmarks of Storage Performance and Availability• Design An I/O System
3
Introduction
4
Motivation: Who Cares About I/O?
• CPU Performance: 2 times very 18 months• I/O performance limited by mechanical delays (disk I/O)
– < 10% per year (I/O per sec or MB per sec)
• Amdahl's Law: system speed-up limited by the slowest part!– 10% I/O & 10x CPU 5x Performance (lose 50%)– 10% I/O & 100x CPU 10x Performance (lose 90%)
• I/O bottleneck: – Diminishing fraction of time in CPU– Diminishing value of faster CPUs
5
Position of I/O in Computer Architecture – Past
• An orphan in the architecture domain• I/O meant the non-processor and memory stuff
– Disk, tape, LAN, WAN, etc.– Performance was not a major concern
• Devices characterized as:– Extraneous, non-priority, infrequently used, slow
• Exception is swap area of disk– Part of the memory hierarchy– Hence part of system performance but you’re hosed if you use it
often
6
Position of I/O in Computer Architecture – Now
• Trends – I/O is the bottleneck– Communication is frequent
• Voice response & transaction systems, real-time video• Multimedia expectations
– Even standard networks come in gigabit/sec flavors – For multi-computers
• Result– Significant focus on system bus performance
• Common bridge to the memory system and the I/O systems• Critical performance component for the SMP server platforms
7
System vs. CPU Performance
• Care about speed at which user jobs get done– Throughput - how many jobs/time (system view)– Latency - how quick for a single job (user view)– Response time – time between when a command is issued and
results appear (user view)
• CPU performance main factor when:– Job mix fits in the memory there are very few page faults
• I/O performance main factor when:– The job is too big for the memory - paging is dominant– When the job reads/writes/creates a lot of unexpected files
• OLTP – Decision support -- Database– And then there is graphics & specialty I/O devices
8
System Performance
• Depends on many factors in the worst case– CPU
– Compiler
– Operating System
– Cache
– Main Memory
– Memory-IO bus
– I/O controller or channel
– I/O drivers and interrupt handlers
– I/O devices: there are many types
• Level of autonomous behavior
• Amount of internal buffer capacity
• Device specific parameters for latency and throughput
9
I/O Systems
Processor
Cache
Memory - I/O Bus
MainMemory
I/OController
Disk Disk
I/OController
I/OController
Graphics Network
interruptsinterrupts
May the same or differentMemory – I/O Bus
10
Keys to a Balanced System
• It’s all about overlap - I/O vs CPU– Timeworkload = Timecpu + TimeI/O - Timeoverlap
• Consider the benefit of just speeding up one– Amdahl’s Law (see P4 as well)
• Latency vs. Throughput
11
I/O System Design Considerations
• Depends on type of I/O device– Size, bandwidth, and type of transaction– Frequency of transaction– Defer vs. do now
• Appropriate memory bus utilization• What should the controller do
– Programmed I/O– Interrupt vs. polled– Priority or not– DMA– Buffering issues - what happens on over-run– Protection– Validation
12
Types of I/O Devices
• Behavior– Read, Write, Both – Once, multiple– Size of average transaction– Bandwidth– Latency
• Partner - the speed of the slowest link theory– Human operated (interactive or not)– Machine operated (local or remote)
13
Is I/O Important?
• Depends on your application– Business - disks for file system I/O– Graphics - graphics cards or special co-processors– Parallelism - the communications fabric
• Our focus = mainline uniprocessing– Storage subsystems (Chapter 7)– Networks (Chapter 8)
• Noteworthy Point– The traditional orphan– But now often viewed more as a front line topic
14
Types of Storage Devices
15
Magnetic Disks
• 2 important Roles– Long term, non-volatile storage – file system and OS– Lowest level of the memory hierarchy
• Most of the virtual memory is physically resident on the disk
• Long viewed as a bottleneck– Mechanical system slow– Hence they seem to be an easy target for improved technology– Disk improvement w.r.t. density have done better than Moore’s law
16
Disks are organized into platters, tracks, and sectors
(1-12 * 2 sides)
(5000 – 30000 each surface)
(100 – 500)
A sector is the smallestunit that can be read or written
17
Physical Organization Options
• Platters – one or many• Density - fixed or variable
– All tracks have the same no. of sectors?)
• Organization - sectors, cylinders, and tracks– Actuators - 1 or more– Heads - 1 per track or 1 per actuator– Access - seek time vs. rotational latency
• Seek related to distance but not linearly• Typical rotation: 3600 RPM or 15000 RPM
• Diameter – 1.0 to 3.5 inches
18
Typical Physical Organization
• Multiple platters– Metal disks covered with magnetic recording material on both sides
• Single actuator (since they are expensive)– Single R/W head per arm– One arm per surface– All heads therefore over same cylinder
• Fixed sector size• Variable density encoding• Disk controller – usually built in processor + buffering
19
Anatomy of a Read Access
• Steps– Memory mapped I/O over bus to controller– Controller starts access– Seek + rotational latency wait– Sector is read and buffered (validity checked)– Controller says ready or DMA’s to main memory and then says
ready
20
Access Time
• Access Time– Seek time: time to move the arm over the proper track
• Very non-linear: accelerate and decelerate times complicate– Rotation latency (delay): time for the requested sector to rotate
under the head (on average: 0.5 * RPM)– Transfer time: time to transfer a block of bits (typically a sector)
under the read-write head– Controller overhead: the overhead the controller imposes in
performing an I/O access– Queuing delay: time spent waiting for a disk to become free
ayQueuingDelOverheadControllermeTransferTiayationalDelAverageRotkTimeAverageSeeessTimeAverageAcc
21
Access Time Example
• Assumption: average seek time – 5ms; transfer rate – 40MB/sec; 10,000 RPM; controller overhead – 0.1ms; no queuing delay
• What is the average time to r/w a 512-byte sector?• Answer
msRPSRPM
msmsMBKB
RPMms
0.3sec003.0)60
10000(
5.0
10000
5.0
1.81.0013.00.30.51.0
sec0.405.0
10000
5.05
22
Cost VS Performance
• Large-diameter drives have many more data to amortize the cost of electronics lowest cost per GB
• Higher sales volume lower manufacturing cost• 3.5-inch drive, the largest surviving drive in 2001, also has
the highest sales volume, so it unquestionably has the best price per GB
23
Future of Magnetic Disks
• Areal density: bits/unit area is common improvement metric• Trends
– Until 1988: 29% improvement per year– 1988 – 1996: 60% per year– 1997 – 2001: 100% per year
• 2001– 20 billion bits per square inch– 60 billion bit per square inch demonstrated in labs
OnATrackInch
BitsfaceOnADiskSur
Inch
TrackstyArealDensi *
24
Disk Price Trends by Capacity
25
Disk Price Trends – Dollars Per MB
26
Cost VS Access Time for SRAM, DRAM, and Magnetic Disk
27
Disk Alternatives
• Optical Disks– Optical compact disks (CD) – 0.65GB– Digital video discs, digital versatile disks (DVD) – 4.7GB * 2 sides– Rewritable CD (CD-RW) and write-once CD (CD-R)– Rewritable DVD (DVD-RAM) and write-once DVD (DVD-R)
• Robotic Tape Storage• Optical Juke Boxes• Tapes – DAT, DLT• Flash memory
– Good for embedded systems– Nonvolatile storage and rewritable ROM
28
Bus – Connecting I/O Devices to CPU/Memory
29
I/O Connection Issues
• Shared communication link between subsystems– Typical choice is a bus
• Advantages– Shares a common set of wires and protocols low cost– Often based on standard - PCI, SCSI, etc. portable and versatility
• Disadvantages– Poor performance– Multiple devices imply arbitration and therefore contention– Can be a bottleneck
Connecting the CPU to the I/O device world
30
I/O Connection Issues – Multiple Buses
• I/O bus– Lengthy
– Many types of connected devices
– Wide range in device bandwidth
– Follow a bus standard
– Accept devices varying in latency and bandwidth capabilities
• CPU-memory bus– Short
– High speed
– Match to the memory system to maximize CPU-memory bandwidth
– Knows all types of devices that must connect together
31
Typical Bus Synchronous Read Transaction
32
Bus Design Decisions
• Other things to standardize as well– Connectors– Voltage and current levels– Physical encoding of control signals– Protocols for good citizenship
33
Bus Design Decisions (Cont.)
• Bus master: devices that can initiate a R/W transaction– Multiple : multiple CPUs, I/O device initiate bus transactions– Multiple bus masters need arbitration (fixed priority or random)
• Split transaction for multiple masters– Use packets for the full transaction (does not hold the bus)– A read transaction is broken into read-request and memory-reply
transactions– Make the bus available for other masters while the data is
read/written from/to the specified address– Transactions must be tagged– Higher bandwidth, but also higher latency
34
Split Transaction Bus
35
Bus Design Decisions (Cont.)
• Clocking: Synchronous vs. Asynchronous– Synchronous
• Include a clock in the control lines, and a fixed protocol for address and data relative to the clock
• Fast and inexpensive (little or no logic to determine what's next)• Everything on the bus must run at the same clock rate• Short length (due to clock skew)• CPU-memory buses
– Asynchronous• Easier to connect a wide variety of devices, and lengthen the bus• Scale better with technological changes• I/O buses
36
Synchronous or Asynchronous?
37
Standards
• The Good– Let the computer and I/O-device designers work independently– Provides a path for second party (e.g. cheaper) competition
• The Bad– Become major performance anchors– Inhibit change
• How to create a standard– Bottom-up
• Company tries to get standards committee to approve it’s latest philosophy in hopes that they’ll get the jump on the others (e.g. S bus, PC-AT bus, ...)
• De facto standards– Top-down
• Design by committee (PCI, SCSI, ...)
38
Connecting the I/O Bus
• To main memory– I/O bus and CPU-memory bus may the same
• I/O commands on bus could interfere with CPU's access memory– Since cache misses are rare, does not tend to stall the CPU– Problem is lack of coherency– Currently, we consider this case
• To cache• Access
– Memory-mapped I/O or distinct instruction (I/O opcodes)
• Interrupt vs. Polling• DMA or not
– Autonomous control allows overlap and latency hiding– However there is a cost impact
39
A typical interface of I/O devices and an I/O bus to the CPU-memory bus
40
Processor Interface Issues
• Processor interface– Interrupts– Memory mapped I/O
• I/O Control Structures– Polling– Interrupts– DMA– I/O Controllers– I/O Processors
• Capacity, Access Time, Bandwidth• Interconnections
– Busses
41
I/O Controller
Command, Interrupt…
I/O Address
Ready, done, error…
42
Memory Mapped I/O
Single Memory & I/O Bus No Separate I/O Instructions
CPU
Interface Interface
Peripheral Peripheral
Memory
ROM
RAM
I/O$
CPU
L2 $
Memory Bus
Memory Bus Adaptor
I/O bus
Some portions of memory address space are assigned to I/O device.Reads/Writes to these space cause data transfer
43
Programmed I/O
• Polling• I/O module performs the action,
on behalf of the processor• But I/O module does not
interrupt CPU when I/O is done• Processor is kept busy checking
status of I/O module– not an efficient way to use the
CPU unless the device is very fast!
• Byte by Byte…
44
Interrupt-Driven I/O
• Processor is interrupted when I/O module ready to exchange data
• Processor is free to do other work
• No needless waiting• Consumes a lot of processor
time because every word read or written passes through the processor and requires an interrupt
• Interrupt per byte
45
Direct Memory Access (DMA)
• CPU issues request to a DMA module (separate module or incorporated into I/O module)
• DMA module transfers a block of data directly to or from memory (without going through CPU)
• An interrupt is sent when the task is complete
– Only one interrupt per block, rather than one interrupt per byte
• The CPU is only involved at the beginning and end of the transfer
• The CPU is free to perform other tasks during data transfer
46
Input/Output Processors
CPU IOP
Mem
D1
D2
Dn
. . .main memory
bus
I/Obus
CPU
IOP
issues instruction to IOP
interrupts when done(1)
memory
(2)
(3)
(4)
Device to/from memorytransfers are controlledby the IOP directly.
IOP steals memory cycles.
OP Device Address
target devicewhere cmnds are
looks in memory for commands
OP Addr Cnt Other
whatto do
whereto putdata
howmuch
specialrequests
47
RAID: Redundant Arrays of Inexpensive Disks
48
3 Important Aspects of File Systems
• Reliability – is anything broken?– Redundancy is main hack to increased reliability
• Availability – is the system still available to the user?– When single point of failure occurs is the rest of the system still
usable?– ECC and various correction schemes help (but cannot improve
reliability)
• Data Integrity– You must know exactly what is lost when something goes wrong
49
Disk Arrays
• Multiple arms improve throughput, but not necessarily improve latency
• Striping– Spreading data over multiple disks
• Reliability– General metric is N devices have 1/N reliability
• Rule of thumb: MTTF of a disk is about 5 years– Hence need to add redundant disks to compensate
• MTTR ::= mean time to repair (or replace) (hours for disks)• If MTTR is small then the array’s MTTF can be pushed out
significantly with a fairly small redundancy factor
50
Data Striping
• Bit-level striping: split the bit of each bytes across multiple disks– No. of disks can be a multiple of 8 or divides 8
• Block-level striping: blocks of a file are striped across multiple disks; with n disks, block i goes to disk (i mod n)+1
• Every disk participates in every access– Number of I/O per second is the same as a single disk– Number of data per second is improved
• Provide high data-transfer rates, but not improve reliability
51
Redundant Arrays of Disks
• Files are "striped" across multiple disks• Availability is improved by adding redundant disks
– If a single disk fails, the lost information can be reconstructed from redundant information
– Capacity penalty to store redundant information– Bandwidth penalty to update
• RAID– Redundant Arrays of Inexpensive Disks– Redundant Arrays of Independent Disks
52
Raid Levels, Reliability, Overhead Redundant
information
53
RAID Levels 0 - 1
• RAID 0 – No redundancy (Just block striping)– Cheap but unable to withstand even a single failure
• RAID 1 – Mirroring – Each disk is fully duplicated onto its "shadow“– Files written to both, if one fails flag it and get data from the mirror– Reads may be optimized – use the disk delivering the data first– Bandwidth sacrifice on write: Logical write = two physical writes– Most expensive solution: 100% capacity overhead– Targeted for high I/O rate , high availability environments
• RAID 0+1 – stripe first, then mirror the stripe• RAID 1+0 – mirror first, then stripe the mirror
54
RAID Levels 2 & 3
• RAID 2 – Memory style ECC– Cuts down number of additional disks
– Actual number of redundant disks will depend on correction model
– RAID 2 is not used in practice
• RAID 3 – Bit-interleaved parity– Reduce the cost of higher availability to 1/N (N = # of disks)
– Use one additional redundant disk to hold parity information
– Bit interleaving allows corrupted data to be reconstructed
– Interesting trade off between increased time to recover from a failure and cost reduction due to decreased redundancy
– Parity = sum of all relative disk blocks (module 2)
• Hence all disks must be accessed on a write – potential bottleneck
– Targeted for high bandwidth applications: Scientific, Image Processing
55
P100100111100110110010011
. . .
logical record 10010011
11001101
10010011
00110000
Striped physicalrecords
25% capacity cost for parity in this configuration (1/N)
RAID Level 3: Parity Disk (Cont.)
56
RAID Levels 4 & 5 & 6
• RAID 4 – Block interleaved parity– Similar idea as RAID 3 but sum is on a per block basis– Hence only the parity disk and the target disk need be accessed– Problem still with concurrent writes since parity disk bottlenecks
• RAID 5 – Block interleaved distributed parity– Parity blocks are interleaved and distributed on all disks– Hence parity blocks no longer reside on same disk– Probability of write collisions to a single drive are reduced– Hence higher performance in the consecutive write situation
• RAID 6– Similar to RAID 5, but stores extra redundant information to guard
against multiple disk failures
57
Raid 4 & 5 Illustration
RAID 4 RAID 5
Targeted for mixed applicationsA logical write becomes four physical I/Os
58
Small Write Update on RAID 3
59
Small Writes Update on RAID 4/5
RAID-5: Small Write Algorithm
D0 D1 D2 D3 PD0'
+
+
D0' D1 D2 D3 P'
newdata
olddata
old parity
XOR
XOR
(1. Read) (2. Read)
(3. Write) (4. Write)
1 Logical Write = 2 Physical Reads + 2 Physical Writes
60
Errors and Failures in Real Systems
61
Examples
• Berkeley’s Tertiary Disk• Tandem• VAX• FCC
62
Berkeley’s Tertiary Disk18 months of operation
SCSI backplane, cables, Ethernetcables were no more reliable thandata disks
63
Benchmarks of Storage Performance and Availability
64
Transaction Processing (TP) Benchmarks
• TP: database applications, OLTP• Concerned with I/O rate (# of disk accesses per second)• Started with anonymous gang of 24 members in 1985
– DebitCredit benchmark: simulate bank tellers and has as it bottom line the number of debit/credit transactions per second (TPS)
• Tighter & more standard benchmark versions– TPC-A, TPC-B– TPC-C: complex query processing - more accurate model of a real
bank which models credit analysis for loans– TPC-D, TPC-H, TPC-R, TPC-W
• Also must report the cost per TPS– Hence machine configuration is considered
65
TP Benchmarks
66
TP Benchmark -- DebitCredit
• Disk I/O is random reads and writes of 100-byte records along with occasional sequential writes– 2—10 disk I/Os per transaction
– 5000 – 20000 CPU instructions per disk I/O
• Performance relies on…– The efficiency of TP software
– How many disk accesses can be avoided by keeping information in main memory (cache) !!! wrong for measuring disk I/O
• Peak TPS– Restriction: 90% of transactions have < 2sec. response time
– For TPS to increase, # of tellers and the size of the account file must also increase (more TPS requires more users)
• To ensure that the benchmark really measure disk I/O (not cache…)
67
Relationship Among TPS, Tellers, and Account File Size
The data set generally must scale in size as the throughput increases
68
SPEC System-Level File Server (SFS) Benchmark
• SPECsfs - system level file server– 1990 agreement by 7 vendors to evaluate NFS performance– Mix of file reads, writes, and file operations– Write: 50% done on 8KB blocks, 50% on partial (1, 2, 4KB)– Read: 85% full block, 15% partial block
• Scales the size of FS according to the reported throughput– For every 100 NFS operations per second, the capacity must
increase by 1GB– Limit average response time, such as 40ms
• Does not normalize for different configuration• Retired in June 2001 due to bugs
69
SPECsfsUnfair configuration
OverallResponse time(ms)
70
SPECWeb
• Benchmark for evaluating the performance of WWW servers• SPECWeb99 workload simulates accesses to a Web server
provider supporting HP for several organizations• For each HP, nine files in each of the four classes
– Less than 1KB (small icons): 35% of activity– 1—10KB: 50% of activity– 10—100KB: 14% of activity– 100KB—1MB (large document and image): 1% of activity
• SPECWeb99 results in 2000 for Dell Computers– Large memory is used for a file cache to reduce disk I/O– Impact of Web server software and OS
71
SPECWeb99 Results for Dell
72
Examples of Benchmarks of Dependability and Availability
• TPC-C has a dependability requirement: must handle a single disk failure
• Brown and Patterson [2000]– Focus on the effectiveness of fault tolerance in systems– Availability can be measured by examining the variations in system
QOS metrics over time as faults are injected into the system– The initial experiment injected a single disk fault
• Software RAID by Linux, Solaris, and Windows 2000– Reconstruct data onto a hot spare disk
• Disk emulator injects faults• SPECWeb99 workload
73
Availability Benchmark for Software RAID
(Red Hat 6.0) (Solaris 7)
74
Availability Benchmark for Software RAID (Cont.)
(Windows 2000)
75
Availability Benchmark for Software RAID (Cont.)
• The longer the reconstruction (MMTF), the lower the availability– Increased reconstruction speed implies decreased application
performance– Linux VS. Solaris and Windows 2000
• RAID reconstruction– Linux and Solaris: initiate reconstruction automatically– Windows 2000: initiate reconstruction manually by operators
• Managing transient faults– Linux: paranoid– Solaris and Windows: ignore most transient faults
76
Designing an I/O System
77
I/O Design Complexities
• Huge variety of I/O devices– Latency– Bandwidth– Block size
• Expansion is a must – longer buses, larger power and cabinets
• Balanced Performance and Cost• Yet another n-dimensional conflicting• Constraint problem
– Yep - it’s NP hard just like all the rest– Experience plays a big role since the solutions are heuristic
78
7 Basic I/O Design Steps
• List types of I/O devices and buses to be supported• List physical requirements of I/O devices
– Volume, power, bus slots, expansion slots or cabinets, ...
• List cost of each device and associated controller• List the reliability of each I/O device• Record CPU resource demands - e.g. cycles
– Start, support, and complete I/O operation
– Stalls due to I/O waits
– Overhead - e.g. cache flushes and context switches
• List memory and bus bandwidth demands• Assess the performance of different ways to organize I/O devices
– Of course you’ll need to get into queuing theory to get it right
79
An Example
• Impact on CPU of reading a disk page directly into cache.• Assumptions
– 16KB page, 64-bytes cache-block
– Addresses of the new page are not in the cache
– CPU will not access data in the new page
– 95% displaced cache block will be read in again (miss)
– Write-back cache, 50% are dirty
– I/O buffers a full cache block before writing to cache
– Access and misses are spread uniformly to all cache blocks
– No other interference between CPU and I/O for the cache slots
– 15,000 misses per 1 million clock cycles when no I/O
– Miss penalty = 30 CC, 30 CC mores to write dirty-blocks
– 1 page is brought in every 1 million clock cycles
80
An Example (Cont.)
• Each page fills 16,384/64 or 256 blocks• 0.5 * 256 * 30 CCs to write dirty blocks to memory• 95% * 256 (244) are referenced again and misses
– All of them are dirty and will need to be written back when replaced– 244 * 60 more CCs to write back
• In total: 128 * 30 + 244 * 60 more CCs than 1,000,000+15,000*30+7,500*30– 1% decrease in performance
81
Five More Examples
• Naive cost-performance design and evaluation• Availability of the first example• Response time of the first example• Most realistic cost-performance design and evaluation• More realistic design for availability and its evaluation