Any modern computer system will incorporate (at least) two levels of storage:

Transcription

1 1 Any moden compute system will incopoate (at least) two levels of stoage: pimay stoage: andom access memoy (RAM) typical capacity 32MB to 1GB cost pe MB $3. typical access time 5ns to 6ns bust tansfe ate?? seconday stoage: magnetic disk/optical devices/tape systems typical capacity GB to 1GB fo fixed media; fo emovable cost pe MB $.1 fo fixed media, moe fo emovable typical access time ms to 12ms fo fixed media, lage fo emovable bust tansfe ate?? Note: all statistics hee ae guaanteed invalid by July 1, 2. Units of Measuement Spatial units: 2 byte (B) kilobyte (KB) megabyte (MB) gigabyte (GB) Time units: nanosecond (ns) micosecond (µs) millisecond (ms) bits 12 o 2 1 bytes 12 kilobytes o 2 2 bytes* 12 megabytes o 2 3 bytes one-billionth (1-9 ) of a second one-millionth (1-6 ) of a second one-thousandth (1-3 ) of a second * Most, if not all, seconday stoage vendos lie about this and call 1,, bytes a megabyte and 1,,, bytes a gigabyte. We will ignoe the issue.

2 Pimay vesus 3 While the paticula values given ealie ae volatile, the elative pefomances suggested ae actually quite stable: Pimay stoage: costs seveal hunded times as much pe unit as seconday stoage. has access times that ae 25, to 1,, times faste than seconday stoage has tansfe ates that ae?? times faste than seconday stoage Why do WE cae (in a data stuctues class)? Often data must be fist ead fom disk into memoy fo pocessing, and then esults must be witten back to disk afte pocessing. In many cases, data sets ae too lage to stoe in memoy at once. File Stoage In many file systems, space is allocated in fixed-size chunks called clustes. Typical cluste sizes ange fom 1KB up to 32KB, usually equaling a powe of 2. When a file is stoed on disk, an intege numbe of clustes ae allocated fo the file; since files sizes ae typically not a multiple of the cluste size, this means that a cetain amount of space is wasted to intenal fagmentation. On aveage, ½ of a cluste is wasted pe file stoed. Obviously that adds up but that s not eally ou concen in this couse. The clustes ae also not usually stoed contiguously on the disk. This extenal fagmentation can cause a seious degadation of pefomance when a file is being ead fom o witten to disk. cluste

3 Had Disk Pefomance Factos To illustate the issues, we will conside the physical oganization and behavio of a typical had disk design. Note that the pesentation hee is an ove-simplification and that contempoay had dive designs incopoate contol sophistication not discussed hee. Despite advances, the basic pefomance issues emain the same. 5 We will conside thee pimay factos that affect the time equied to ead equested data fom the disk into memoy: seek time latency tansfe time time fo the appopiate I/O head to each the desied tack time fo the appopiate secto to otate to the I/O head time fo the data to be ead to move past the I/O head Fist we must have a clea pictue of the hadwae Disk Contolles All disk systems incopoate an on-boad contolle which acts as an inteface between the CPU and the disk hadwae. The contolle masks the intenal physical oganization of the disk (coveed in the next few slides) fom the CPU and use pocesses. The contolle has an intenal cache (typically 256KB up to seveal MB) that it uses to buffe data fo ead/wite equests. 6 Disk Contolle Physical Disk Contolle Cache Slots

4 Plattes and I/O Heads A typical had dive contains a numbe of cicula plattes, attached to a otating spindle. Each platte holds data on one o both of its sufaces. The data is ead and witten by I/O heads, typically one pe data suface. These I/O heads ae mounted in a ack and all move in and out in unison. Typically, only one I/O head can be active (eading o witing data) at any given time. ack platte spindle head Tacks and Sectos Each data suface is oganized into concentic ings of data, called tacks. Each tack is divided into a numbe of segments, called sectos. We will assume that each secto contains the same amount of data, egadless of which tack it belongs to. (That is actually tue fo some olde disks.) tack secto The basic unit of disk I/O is the secto. We will see shotly that eading an entie secto fom disk takes only slightly longe than eading a single byte. inte-secto gap

5 Reading a Secto When a disk ead is equested the following actions must be caied out: 9 1. Detemine what secto(s) must be ead the disk contolle is esponsible fo this. 3. Wait fo the beginning of the fist secto to otate to the head. 2. Move the ead head to the tack containing the tageted secto(s).. Read the data as it otates beneath the head. Seek Time seek time the time equied to move the head to the appopiate tack 1 The seek time depends only on the speed with which the head ack moves, and the numbe of tacks that the head must move acoss to each its taget. Given the following (which ae constant fo a paticula disk): H s = the time fo the I/O head to stat moving H T = the time fo the I/O head to move fom one tack to the next then the time fo the head to move n tacks is: Seek( n ) = H s + H T n QTP: On aveage, the head will move 1/3 of the way acoss the platte. Why?

6 Rotational Latency Time latency the time equied fo the appopiate secto to otate to the position of the I/O head The otational latency time depends only on the speed at which the spindle otates, and the angle though which the tack must otate to each the I/O head. Given the following: R = the otational speed of the spindle (in otations pe second) θ = the numbe of adians though which the tack must otate then the otational latency is: Latency θ 1 2π R ( θ) = 11 On aveage, the latency time will be the time equied fo the platte to complete 1/2 of a full otation. Data Tansfe Time tansfe time the time equied fo the appopiate secto(s) to otate unde the I/O head (fo contiguous sectos on the same tack) 12 The tansfe time depends only on the speed at which the spindle otates, and the numbe of sectos that must be ead. Given: S T = the total numbe of sectos pe tack the tansfe time fo n contiguous sectos on the same tack is: Tansfe n ST 1 R ( n) = Fo sectos on diffeent tacks, each tack must be analyzed sepaately, allowing fo seek and latency.

7 Total Read/Wite Time The total time to ead/wite data is fom/to disk is then the sum of the seek time, the otational latency time, and the tansfe time. This ignoes the time fo contolle logic, delays due to multitasking queues, etc.; that is fai because those times ae nomally odes of magnitude less that the times consideed. One note: we have assumed in the analysis of the data tansfe time that the I/O heads ae capable of eading/witing data as fast as the secto moves beneath the head. On olde disk systems that was often not the case, and inteleaving was necessay to optimize ead/wite pefomance. On most contempoay disk systems, the I/O heads ae fast enough that such ticks ae unnecessay. Example: Contiguous File Read Assume a disk system with the following paametes: 1 Total capacity: 65 MB # of plattes: 15 (3 data sufaces) # of tacks pe platte: 56 # of sectos pe tack: 16 cluste size: KB spindle speed: 36 RPM head stat time: 3 ms head tack tavesal time:. ms Question:how much time would be equied, on aveage, to ead a file of size 1 KB, assuming the file is stoed in contiguous sectos on adjacent tacks (since one tack won t hold the whole file in this case)?

8 Example: Contiguous File Read We must compute some values fom the given disk paametes: 15 otations pe second: 6 capacity of one platte: 5 MB capacity of one tack: KB capacity of one secto: 512 bytes sectos pe cluste: 16 clustes pe tack: 1 So a 1 KB file would occupy 1 clustes, o one full tack plus clustes on an adjacent tack. The last cluste is only patially filled, but we will ignoe that in ou calculations. Fo eading the fist (full) tack, assuming aveage values: - seek time = 3 + (56/3)*. = 1.36 ms - latency time = (1/2)*(1/6) =.33 ms total: 3.36 ms - tansfe time = (16/16)*(1/6) = 16.6 ms Example: Contiguous File Read 16 Fo eading the elevant sectos fom the second tack, assuming aveage values: - seek time = 3 + (1)*. = 3.36 ms - latency time = (1/2)*(1/6) =.33 ms total: 2. ms - tansfe time = (12/16)*(1/6) =.33 ms So the total time to ead the file into memoy* would be about 6.1 ms. * Actually this is the time to ead the file into the disk buffe memoy.

9 Example: Fagmented File Read What if the file is scatteed all ove the disk? Then it will take a lot longe fo each cluste: - seek time = 3 + (56/3)*. = 1.36 ms - latency time = (1/2)*(1/6) =.33 ms - tansfe time = (16/16)*(1/6) = 1.6 ms total: 2.36 ms Since the file occupies (pat o all of) 1 clustes, the total ead time fo a completely fagmented copy of the file would be about 51. ms. Secto Read vs Single Byte Read 1 The pogams you have implemented simply pefom ead/wite actions, usually on single vaiables which may stoe fom 1 to a few hunded bytes of data. Why do typical disk contolles pefom ead/wite opeations in secto-sized chunks? Pefomance given the disk system descibed ealie: time to ead one full tack: 3.36 ms (slide 15) time to ead one full secto: 26.9 ms 1.36 ms +.33 ms + (1/16)*(1/6) time to ead one byte: ms 1.36 ms +.33 ms + (1/512)*(1/16)*(1/6) The time to ead one secto is only slightly moe than the time to ead a single byte, lagely because the seek and latency times dominate the tansfe time.

10 Locality of Refeence 19 In view of the pevious slide, it makes sense to design pogams so that data is ead fom and witten to disk in elatively lage chunks but thee is moe. Spatial Locality of Refeence In many cases, if a pogam accesses one pat of a file, thee is a high pobability that the pogam will access neaby pats of the file in the nea futue. Tempoal Locality of Refeence Moal: gab a lage chunk than you immediately need. In many cases, if a pogam accesses one pat of a file, thee is a high pobability that the pogam will access the same pat of the file again in the nea futue. Moal: once you ve gabbed a chunk, keep it aound. Buffe Pools 2 buffe pool a seies of buffes (memoy locations) used by a pogam to cache disk data A pogam that does much disk I/O can often impove its pefomance by employing a buffe pool to take advantage of locality of efeence. Basically, the buffe pool is just a collection of data chunks. The pogam eads and wites data in buffe-sized chunks, stoing newly-ead data chunks into the pool, eplacing cuently stoed chunks as necessay. Executing pocess disk ead equest seved disk data Buffe Pool data1 data3 data5 Disk Contolle

11 Replacement Stategies The buffe pool must be oganized physically and logically. The physical oganization is geneally an odeed list of some sot. The logical oganization depends upon how the buffe pool deals with the issue of eplacement if a new data chunk must be added to the pool and all the buffes ae cuently full, one of the cuent elements must be eplaced. If the eplaced element has been modified, it (usually) must be witten back to disk o the changes will be lost. 21 Common buffe eplacement stategies: FIFO (fist-in is fist-out) oganize buffes as a queue LFU (least fequently used) eplace the least-accessed buffe LRU (least ecently used) eplace the longest-idle buffe FIFO Replacement Logically the buffe pool is teated as a queue: 22 Requested "chunks":... a a Takes no notice of the access patten exhibited by the pogam. Conside what would happen with the sequence:

12 LFU Replacement Fo LFU we must maintain an access count fo each element of the buffe pool. It is also useful to keep the elements soted by that count. 23 Requested "chunks":...,1,1,1,1,1,2,2,2,2,1,1,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 a Aside fom cost of stoing and maintaining counte values, and seaching fo least value, conside the sequence: (5 times) 1 (5 times) LRU Replacement With LRU, we may use a simple list stuctue. On an access, we move the tageted element to the font of the list. That puts the least ecently used element at the tail of the list. 2 Requested "chunks":... a Conside what would happen with the sequence:

13 Compaison In geneal, none of these eplacement stategies is best in all cases. All ae used with some fequency. Intuitively, LRU and LFU make moe sense than FIFO. The pefomance you get is detemined by the access patten exhibited by the unning pogam, and that is often impossible to pedict. 25 Optimal buffe eplacement stategy: eplace the buffe element whose next access lies futhest in the futue. Buffe Pool Design 26 Thee ae some geneal popeties a good buffe pool will have: - the buffe size and numbe of buffes should be client-configuable - the buffe pool should deal only in "aw bytes"; i.e., it should not know anything at all about the intenals of the data ecod fomat used by the client code (This may be elaxed in some cases, but it is geneally a good policy, especially if the buffeed file is binay.) - if ecods ae fixed-length then each buffe should hold an intege numbe of ecods; fo vaiable-length ecods, things ae moe complex and it is often necessay fo buffes to include some intenal fagmentation Optimal buffe eplacement stategy: eplace the buffe element whose next access lies futhest in the futue.

14 Buffe Pool Inteface 2 Hee is a sample buffe pool inteface fo a binay file: class FIFOBuffePool { pivate: int buffesize; int numbuffes; int maxbuffes; int Font; int Rea; Buffe** Buff; bool* Dity; fsteam* db; void Inset(Buffe toadd); int isbuffeed(int fileoffset) const; void witeback(int buffeidx); public: FIFOBuffePool(); FIFOBuffePool(int Size, int Buffes, fsteam* In); FIFOBuffePool(const FIFOBuffePool& Souce); FIFOBuffePool opeato=(const FIFOBuffePool& Souce); }; cha* Get(int fileoffset); void Put(cha* toput, int fileoffset, int Size); void flushtodisk(); ~FIFOBuffePool(); Buffe Element Inteface And hee is a sample buffe element fo a binay file: class Buffe { public: int Offset; int buffesize; cha* B; Buffe(); Buffe(int Size, int Off); Buffe(const Buffe& Souce); Buffe opeato=(const Buffe& Souce); ~Buffe(); }; 2 The buffe pool uses a FIFO list to stoe a collection of dynamically-allocated buffe elements. Data is stoed using dynamically-allocated cha aays since that allows handling a collection of unintepeted bytes. See the notes on binay file I/O fo details.