Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Various aspects of i/o systems, including i/o devices, performance issues, disk organization, and disk performance optimizations. It discusses the challenges of handling interrupts from i/o devices, the organization of magnetic disks, and methods for optimizing disk performance. The document also touches on disk technology trends.
Typology: Slides
1 / 16
This page cannot be seen from the preview
Don't miss anything!
n Typically, IO devices generate an interrupt when something happens
n Three alternatives:
n Raise an interrupt for every byte transferred from/to the I/O device
n Do block transfers to memory (direct memory access or DMA) and raise interrupt when transfer is done
n Bitmap display – CPU writes to video memory what should be displayed, display reads video memory, illuminating pixels n Done at user-level without kernel intervention
n Raise an interrupt for every character n CPU could get swamped due to “overhead” of handling each byte n Example: 10 terminals connect at 9600 baud (about 1KB/s) n 10 thousand interrupts per second n If each interrupt takes 1 us to handle, load = 0.01 secs = 1% n If each interrupt takes 100 us to handle, CPU is loaded
n Overhead to initiate a request n Latency of performing a 1 byte transfer (dominates cost of small I/Os) n Bandwidth of I/O transfer once started (dominates cost of large transfers)
n Circular disk coated with magnetic material
n Concentric rings around disk surface, bits laid out serially along each track
n Each track is split into arc of track (min unit of transfer)
n Depends on locality of access n If reading next sector immediately after reading previous sector, no need to wait n If reading next sector after a small delay, need to wait for disk to finish the current rotation (assuming no track buffers ) n If track buffers, next access within the same track is fast
n If random place in same cylinder n No seek needed n Just rotational delay (3ms) n Transfer (0.04 ms) n Total time is 3.04ms or about 330 KB/sec
n If random place in same cylinder, but read 10KB instead n Rotational delay (3ms) + Transfer (0.4ms) n Total time is 3.4ms or about 3MB/sec
n A lot of disk transfer bandwidth is wasted n Need algorithms to reduce seek time
n For example, reading outer tracks could be 40MB/sec, while reading inner tracks could be 25MB/sec
2Mbytes 90%
1Mbytes 83%
256Kbytes 55%
8Kbytes 3.7%
1Kbytes 0.5%
% of Disk Transfer Bandwidth
Block Size (Kbytes)
n Can we improve both bandwidth and latency?
n First come first serve
n Fairness among requests n In the order applications expect
n Arrival may be on random spots on the disk (long seeks) n Consider files accessed at a server – merging accesses from different users n Wild swings can happen
n Like SCAN n But, wrap around n Real implementation doesn’t go to the end
n Uniform service time
n Do nothing on the return
n Disk controller has a piece of RAM to cache recently accessed blocks n IBM Ultra160 SCSI has 16MB n Some of the RAM space stores “firmware” (an OS) n Blocks are replaced usually in LRU order
n Good for reads if you have locality
n Expensive n Need to deal with reliable writes
n About a factor of 2 per year since 1991
n More bits/square inch n Tracks are closer together n Doubles density every 18 months n Head close to surface
n Spin faster, less rotational delay, higher bandwidth n Less distance for head to travel (faster seeks) n Lighter weight (for portables)
n A fast file system for Unix (Monday: 3/22) n Log Structured File Systems (Wednesday: 3/24)
n Sequential: bytes read in order n Random: read/write element out of middle of arrays n Content-based access: find me next byte starting with “CS422”
n Most files are small n Large files account for most of the bytes transferred n Large files use up most of the disk space
n Need everything to be efficient
n Disk sectors associated with each file
n Bit map n 1 bit per block (or sector) n blocks numbered in cylinder-major order, why? n How much space does a bitmap need for a 4G disk? n Linked list
n first sector in file n number of sectors
n Fast sequential access n Easy random access
n External fragmentation n Hard to grow files
n Can grow files dynamically n Free list is similar to a file n No waste of space
n Sequential access: slow n random access: horrible n unreliable: losing a block means losing the rest
File header
null
outer-index
index table file
n 10 direct pointers n 11: 1-level indirect n 12: 2-level indirect n 13: 3-level indirect
n In favor of small files n Can grow n Limit is 16G (assuming 1K blocks)
1 2
data
data
11 12 13 data
n In (early) Unix & DOS FAT file systems, special array in outermost cylinders
n “i-node” --- file header; “i-number” --- index into the array
n header not anywhere near the data blocks. To read a small file, seek to get header, seek back to data.
n fixed size, set when disk is formatted.
n Reliability: whatever happens to the data, you can find all of the files. n Unix BSD 4.2 puts portion of the file header array on each cylinder. For small directories, can fit all data, file headers, etc. in same cylinder Ë no seeks! n File headers are much smaller than a whole block (a few hundred bytes), so multiple file headers fetched from disk at same time.
n Yes! Reading the header is 4 times more common than reading the file (e.g., ls, make).
n size of the file system n size of the file descriptor area n free list pointer, or pointer to bitmap n location of the file descriptor of the root directory n other meta-data such as permission and various times
Super block
File descriptors (i-node in Unix) File data blocks Boot block
