Operating Systems Design and Implementation, Third Edition phần 4 docx

When the driver receives a message to read or write a block, it just computes where in the RAM disk memory the requested block lies and reads from it or writes to it, instead of from or to a floppy or hard disk. Ultimately the system task is called to carry out the transfer. This is done by phys_copy, an assembly language procedure in the kernel that copies to or from the user program at the maximum speed of which the hardware is capable. Figure 3-20. A RAM disk. A RAM disk driver may support several areas of memory used as RAM disk, each distinguished by a different minor device number. Usually, these areas are distinct, but in some fairly specific situations it may be convenient to have them overlap, as we shall see in the next section. [Page 273] 3.6.2. Overview of the RAM Disk Driver in MINIX 3 The MINIX 3 RAM disk driver is actually six closely related drivers in one. Each message to it specifies a minor device as follows: 0: /dev/ram 2: /dev/kmem 4: /dev/boot 1: /dev/mem 3: /dev/null 5: /dev/zero The first special file listed above, /dev/ram, is a true RAM disk. Neither its size nor its origin is built into the driver. They are determined by the file system when MINIX 3 is booted. If the boot parameters specify that the root file system is to be on the RAM disk but the RAM disk size is not specified, a RAM disk of the same size as the root file system image device is created. A boot parameter can be used to specify a RAM disk larger than the root file system, or if the root is not to be copied to the RAM, the specified size may be any 2 2 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com value that fits in memory and leaves enough memory for system operation. Once the size is known, a block of memory big enough is found and removed from the memory pool by the process manager during its initialization. This strategy makes it possible to increase or reduce the amount of RAM disk present without having to recompile the operating system. The next two minor devices are used to read and write physical memory and kernel memory, respectively. When /dev/mem is opened and read, it yields the contents of physical memory locations starting at absolute address zero (the real-mode interrupt vectors). Ordinary user programs never do this, but a system program concerned with debugging the system might possibly need this facility. Opening /dev/mem and writing on it will change the interrupt vectors. Needless to say, this should only be done with the greatest of caution by an experienced user who knows exactly what he is doing. The special file /dev/kmem is like /dev/mem, except that byte 0 of this file is byte 0 of the kernel's data memory, a location whose absolute address varies, depending on the size of the MINIX 3 kernel text segment. It too is used mostly for debugging and very special programs. Note that the RAM disk areas covered by these two minor devices overlap. If you know exactly how the kernel is placed in memory, you can open /dev/mem, seek to the beginning of the kernel's data area, and see exactly the same thing as reading from the beginning of /dev/kmem. But, if you recompile the kernel, changing its size, or if in a subsequent version of MINIX 3 the kernel is moved somewhere else in memory, you will have to seek a different amount in /dev/mem to see the same thing you now see at the start of /dev/kmem. Both of these special files should be protected to prevent everyone except the superuser from using them. The next file in this group, /dev/null, is a special file that accepts data and throws them away. It is commonly used in shell commands when the program being called generates output that is not needed. For example, a.out >/dev/null [Page 274] runs the program a.out but discards its output. The RAM disk driver effectively treats this minor device as having zero size, so no data are ever copied to or from it. If you read from it you will get an immediate EOF (End of File). If you have looked at the directory entries for these files in /dev/ you may have noticed that, of those mentioned so far, only /dev/ram is a block special file. All the others are character devices. There is one more block device supported by the memory driver. This is /dev/boot. From the point of view of the device driver it is another block device implemented in RAM, just like /dev/ram. However, it is meant to be initialized by copying a file appended to the boot image after init into memory, rather than starting with an empty block of memory, as is done for /dev/ram. Support for this device is provided for future use and it is not used in MINIX 3 as described in this text. Finally, the last device supported by the memory driver is another character special file, /dev/zero. It is sometimes convenient to have a source of zeros. Writing to /dev/zero is like writing to /dev/null; it throws data away. But reading /dev/zero gives you zeros, in any quantity you want, whether a single character or a disk full. At the driver level, the code for handling /dev/ram, /dev/mem, /dev/kmem, and /dev/boot is identical. The only difference among them is that each one corresponds to a different region of memory, indicated by the arrays ram_origin and ram_limit, each indexed by minor device number. The file system manages devices at a higher level. The file system interprets devices as character or block devices, and thus can mount /dev/ram and /dev/boot and manage directories and files on these devices. For the devices defined as character devices the file system can only read and write streams of data (although a stream read from /dev/null gets only EOF). 3 3 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 3.6.3. Implementation of the RAM Disk Driver in MINIX 3 As with other disk drivers, the main loop of the RAM disk driver is in the file driver.c. The device-specific support for memory devices is in memory.c (line 10800). When the memory driver is compiled, a copy of the object file called drivers/libdriver/driver.o, produced by compiling drivers/libdriver/driver.c, is linked with the object file drivers/memory/memory.o, the product of compiling drivers/memory/memory.c. It may be worth taking a moment to consider how the main loop is compiled. The declaration of the driver structure in driver.h (lines 10829 to 10845) defines a data structure, but does not create one. The declaration of m_dtab on lines 11645 to 11660 creates an instance of this with each part of the structure filled in with a pointer to a function. Some of these functions are generic code compiled when driver.c is compiled, for instance, all of the nop functions. Others are code compiled when memory.c is compiled, for instance, m_do_open. Note that for the memory driver seven of the entries are do-little or do-nothing routines and the last two are defined as NULL (which means these functions will never be called, there is no need even for a do_nop). All this is a sure clue that the operation of a RAM disk is not terribly complicated. [Page 275] The memory device does not require definition of a large number of data structures, either. The array m_geom[NR_DEVS] (line 11627) holds the base and size of each of the six memory devices in bytes, as 64 bit unsigned integers, so there is no immediate danger of MINIX 3 not being able to have a big enough RAM disk. The next line defines an interesting structure that will not be seen in other drivers. M_seg[NR_DEVS] is apparently just an aray of integers, but these integers are indices that allow segment descriptors to be found. The memory device driver is unusual among user-space processes in having the ability to access regions of memory outside of the ordinary text, data, and stack segments every process owns. This array holds the information that allows access to the designated additional memory regions. The variable m_device just holds the index into these arrays of the currently active minor device. To use /dev/ram as the root device the memory driver must be initialized very early during startup of MINIX 3. The kinfo and machine structures that are defined next will hold data retrieved from the kernel during startup that is necessary for initializing the memory driver. One other data structure is defined before the executable code begins. This is dev_zero, an array of 1024 bytes, used to supply data when a read call is made to /dev/zero. The main procedure main (line 11672) calls one function to do some local initialization. After that, it calls the main loop, which gets messages, dispatches to the appropriate procedures, and sends the replies. There is no return to main upon completion. The next function, m_name, is trivial. It returns the string "memory" when called. On a read or write operation, the main loop makes three calls: one to prepare a device, one to do the actual data transfer, and one to do cleanup. For a memory device, a call to m_prepare is the first of these. It checks that a valid minor device has been requested and then returns the address of the structure that holds the base address and size of the requested RAM area. The second call is for m_transfer (line 11706). This does all the work. As we saw in driver.c, all calls to read or write data are transformed into calls to read or write multiple contiguous blocks of dataif only one block is needed the request is passed on as a request for multiple blocks with a count of one. So only two kinds of transfer requests are passed on to the driver, DEV_GATHER, requesting a read of one or more blocks, and DEV_SCATTER, a request to write one or more blocks. Thus, after getting the minor device number, m_transfer enters a loop, repeated for the number of transfers requested. Within the loop there is a switch on the device type. The first case is for /dev/null, and the action is to return immediately on a DEV_GATHER request or on a 4 4 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com DEV_SCATTER request to fall through to the end of the switch. This is so the number of bytes transferred (although this number is zero for /dev/null) can be returned, as would be done for any write operation. [Page 276] For all of the device types that refer to real locations in memory the action is similar. The requested offset is checked against the size of the device to determine that the request is within the bounds of the memory allocated to the device. Then a kernel call is made to copy data either to or from the memory of the caller. There are two chunks of code that do this, however. For /dev/ram, /dev/kmem, and /dev/boot virtual addresses are used, which requires retrieving the segment address of the memory region to be accessed from the m_seg array, and then making a sys_vircopy kernel call (lines 11640 to 11652). For /dev/mem a physical address is used and the call is to sys_physcopy. The remaining operation is a read or write to /dev/zero. For reading the data is taken from the dev_zero array mentioned earlier. You might ask, why not just generate zero values as needed, rather than copying from a buffer full of them? Since the copying of the data to its destination has to be done by a kernel call, such a method would require either an inefficient copying of single bytes from the memory driver to the system task, or building code to generate zeros into the system task. The latter approach would increase the complexity of kernel-space code, something that we would like to avoid in MINIX 3. A memory device does not need a third step to finish a read or write operation, and the corresponding slot in m_dtab is a call to nop_finish. Opening a memory device is done by m_do_open (line 11801). The job is done by calling m_prepare to check that a valid device is being referenced. More interesting than the code that exists is a comment about code that was found here in older versions of MINIX. Previously a trick was hidden here. A call by a user process to open /dev/mem or /dev/kmem would also magically confer upon the caller the ability to execute instructions which access I/O ports. Pentium-class CPUs implement four privilege levels, and user processes normally run at the least-privileged level. The CPU generates a general protection exception when an process tries to execute an instruction not allowed at its privilege level. Providing a way to get around this was considered safe because the memory devices could only be accessed by a user with root privileges. In any case, this possibly risky "feature" is absent from MINIX 3 because kernel calls that allow I/O access via the system task are now available. The comment remains, to point out that if MINIX 3 is ported to hardware that uses memory-mapped I/O such a feature might need to be reintroduced. The function to do this, enable_iop, remains in the kernel code to show how this can be done, although it is now an orphan. The next function, m_init (line 11817), is called only once, when mem_task is called for the first time. This routine uses a number of kernel calls, and is worth study to see how MINIX 3 drivers interact with kernel space by using system task services. First a sys_getkinfo kernel call is made to get a copy of the kernel's kinfo data. From this data it copies the base address and size of /dev/kmem into the corresponding fields of the m_geom data structure. A different kernel call, sys_segctl, converts the physical address and size of /dev/kmem into the segment descriptor information needed to treat the kernel memory as a virtual memory space. If an image of a boot device has been compiled into the system boot image, the field for the base address of /dev/boot will be non-zero. If this is so, then information to access the memory region for this device is set up in exactly the same way it was done for /dev/kme m. Next the array used to supply data when /dev/zero is accessed is explicitly filled with zeros. This is probably unnecessary; C compilers are supposed to initialize newly created static variables to all zeros. [Page 277] Finally, m_init uses a sys_getmachine kernel call to get another set of data from the kernel, the machine structure which flags various possible hardware alternatives. In this case the information needed is whether or 5 5 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com not the CPU is capable of protected mode operation. Based on this information the size of /dev/mem is set to either 1 MB, or 4 GB - 1, depending upon whether MINIX 3 is running in 8088 or 80386 mode. These sizes are the maximum sizes supported by MINIX 3 and do not have anything to do with how much RAM is installed in the machine. Only the size of the device is set; the compiler is trusted to set the base address correctly to zero. Also, since /dev/mem is accessed as physical (not virtual) memory there is no need to make a sys_segctl kernel call to set up a segment descriptor. Before we leave m_init we should mention another kernel call used here, although it is not obvious in the code. Many of the actions taken during initialization of the memory driver are essential to proper functioning of MINIX 3, and thus several tests are made and panic is called if a test fails. In this case panic is a library routine which ultimately results in a sys_exit kernel call. The kernel and (as we shall see) the process manager and the file system have their own panic routines. The library routine is provided for device drivers and other small system components. Surprisingly, the function we just examined, m_init, does not initialize the quintessential memory device, /dev/ram. This is taken care of in the next function, m_ioctl (line 11863). In fact, there is only one ioctl operation defined for the RAM disk; this is MIOCRAMSIZE, which is used by the file system to set the RAM disk size. Much of the job is done without requiring any services from the kernel. The call to allocmem on line 11887 is a system call, but not a kernel call. It is handled by the process manager, which maintains all of the information necessary to find an available region of memory. However, at the end one kernel call is needed. At line 11894 a sys_segctl call is made to convert the physical address and size returned by allocmem into the segment information needed for further access. The last function defined in memory.c is m_geometry. This is a fake. Obviously, cylinders, heads, and sectors are irrelevant in addressing semiconductor memory, but if a request is made for such information for a memory device this function pretends it has 64 heads and 32 sectors per track, and calculates from the size how many cylinders there are. 6 6 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [Page 278] 3.7. Disks All modern computers except embedded ones have disk drives. For that reason, we will now study them, starting with the hardware, then moving on to say some general things about disk software. After that we will delve into the way MINIX 3 controls its disks. 3.7.1. Disk Hardware All real disks are organized into cylinders, each one containing as many tracks as there are heads stacked vertically. The tracks are divided into sectors, with the number of sectors around the circumference typically being 8 to 32 on floppy disks, and up to several hundred on some hard disks. The simplest designs have the same number of sectors on each track. All sectors contain the same number of bytes, although a little thought will make it clear that sectors close to the outer rim of the disk will be physically longer than those close to the hub. The time to read or write each sector will be same, however. The data density is obviously higher on the innermost cylinders, and some disk designs require a change in the drive current to the read-write heads for the inner tracks. This is handled by the disk controller hardware and is not visible to the user (or the implementer of an operating system). The difference in data density between inner and outer tracks means a sacrifice in capacity, and more sophisticated systems exist. Floppy disk designs that rotate at higher speeds when the heads are over the outer tracks have been tried. This allows more sectors on those tracks, increasing disk capacity. Such disks are not supported by any system for which MINIX 3 is currently available, however. Modern large hard drives also have more sectors per track on outer tracks than on inner tracks. These are IDE (Integrated Drive Electronics) drives, and the sophisticated processing done by the drive's built-in electronics masks the details. To the operating system they appear to have a simple geometry with the same number of sectors on each track. The drive and controller electronics are as important as the mechanical hardware. The main element of the disk controller is a specialized integrated circuit, really a small microcomputer. Once this would have been on a card plugged into the computer's backplane, but on modern systems, the disk controller is on the parentboard. For a modern hard disk this disk controller circuitry may be simpler than for a floppy disk, since a hard drive has a powerful electronic controller integrated into the drive itself. A device feature that has important implications for the disk driver is the possibility of a controller doing seeks on two or more drives at the same time. These are known as overlapped seeks. While the controller and software are waiting for a seek to complete on one drive, the controller can initiate a seek on another drive. Many controllers can also read or write on one drive while seeking on one or more other drives, but a floppy disk controller cannot read or write on two drives at the same time. (Reading or writing requires the controller to move bits on a microsecond time scale, so one transfer uses up most of its computing power.) The situation is different for hard disks with integrated controllers, and in a system with more than one of these hard drives they can operate simultaneously, at least to the extent of transferring between the disk and the controller's buffer memory. Only one transfer between the controller and the system memory is possible at once, however. The ability to perform two or more operations at the same time can reduce the average access time considerably. [Page 279] One thing to be aware of in looking at the specifications of modern hard disks is that the geometry specified, and used by the driver software, is almost always different from the physical format. In fact, if you look up the 1 1 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com "recommended setup parameters" for a large hard disk, you are likely to find it specified as 16383 cylinders, 16 heads, and 63 sectors per track, no matter what the size of the disk. These numbers correspond to a disk size of 8 GB, but are used for all disks this size or larger. The designers of the original IBM PC ROM BIOS allotted a 6-bit field for the sector count, 4 bits to specify the head, and 14 bits to select a cylinder. With 512 byte sectors this comes out to 8 GB. So if you try to install a large hard drive into a very old computer you may find you can access only 8 GB, even though you have a much bigger disk. The usual way around this limitation is to use logical block addressing in which disk sectors are just numbered consecutively starting at zero, without regard to the disk geometry. The geometry of a modern disk is a fiction, anyway. On a modern disk the surface is divided into 20 or more zones. Zones closer to the center of the disk have fewer sectors per track than zones nearer the periphery. Thus sectors have approximately the same physical length no matter where they are located on the disk, making more efficient use of the disk surface. Internally, the integrated controller addresses the disk by calculating the zone, cylinder, head, and sector. But this is never visible to the user, and the details are rarely found in published specifications. The bottom line is, there is no point to using cylinder, head, sector addressing of a disk unless you are working with a very old computer that does not support logical block addressing. Also, it does not make sense to buy a new 400 GB drive for the PC-XT you bought in 1983; you will get no more than 8 GB use out of it. This is a good place to mention a confusing point about disk capacity specifications. Computer professionals are accustomed to using powers of 2a Kilobyte (KB) is 2 10 = 1024 bytes, a Megabyte (MB) is 2 20 = 1024 2 bytes, etc., to express the size of memory devices. A Gigabyte (GB), then, should be 1024 3 , or 2 30 bytes. However, disk manufacturers have adopted the habit of using the term "Gigabyte" to mean 10 9 , which (on paper) instantly increases the size of their products. Thus the 8 GB limit mentioned above is an 8.4 GB disk in the language of the disk salesman. Recently there has been a move toward using the term Gibibyte (GiB) to mean 2 30 . However, in this text the authors, being set in their ways and in protest of the hijacking of tradition for advertising purposes, will continue to use terms like Megabyte and Gigabyte to mean what they have always meant. [Page 280] 3.7.2. RAID Although modern disks are much faster than older ones, improvements in CPU performance have far exceeded improvements in disk performance. It has occurred to various people over the years that parallel disk I/O might be helpful. Thus has come about a new class of I/O device called a RAID, an acronym for Redundant Array of Independent Disks. Actually, the designers of RAID (at Berkeley) originally used the acronym RAID to stand for "Redundant Array of Inexpensive Disks" to contrast this design with a SLED (Single Large Expensive Disk). However, when RAID became commercially popular, disk manufacturers changed the meaning of the acronym because it was tough to sell an expensive product whose name stood for "inexpensive." The basic idea behind a RAID is to install a box full of disks next to the computer, typically a large server, replace the disk controller card with a RAID controller, copy the data over to the RAID, and then continue normal operation. The independent disks can be used together in a variety of ways. We do not have space for an exhaustive description of all of these, and MINIX 3 does not (yet) support RAID, but an introduction to operating systems should at least mention some of the possibilities. RAID can be used both to speed disk access and to make data more secure. For example, consider a very simple RAID of two drives. When multiple sectors of data are to be written to the "disk" the RAID controller sends sectors 0, 2, 4, etc., to the first drive, and sectors 1, 3, 5, etc., to the second drive. The controller divides up the data and the two disks are written simultaneously, doubling the 2 2 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com writing speed. When reading, both drives are read simultaneously, but the controller reassembles the data in the proper order, and to the rest of the system it just looks like the reading speed is twice as fast. This technique is called striping. This is a simple example of RAID level 0. In practice four or more drives would be used. This works best when data are usually read or written in large blocks. Obviously, nothing is gained if a typical disk request is for a single sector at a time. The previous example shows how multiple drives can increase speed. What about reliability? RAID level 1 works like RAID level 0, except the data is duplicated. Again, a very simple array of two drives could be used, and all of the data could be written to both of them. This provides no speedup, but there is 100% redundancy. If an error is detected during reading there is no need for a retry if the other drive reads the data correctly. The controller just has to make sure the correct data is passed on to the system. It probably would not be a good idea to skip retries if errors are detected while writing, however. And if errors occur frequently enough that skipping retries actually makes reading noticeably faster it is probably time to decide complete failure is imminent. Typically the drives used for RAIDs are hot-swappable, meaning they can be replaced without powering down the system. [Page 281] More complex arrays of multiple disks can increase both speed and reliability. Consider, for instance, an array of 7 disks. Bytes could be split into 4-bit nybbles, with each bit being recorded on one of four drives and with the other three drives being used to record a three bit error-correcting code. If a drive goes bad and needs to be hot-swapped for a new one, a missing drive is equivalent to one bad bit, so the system can keep running while maintenance is done. For the cost of seven drives you get reliable performance that is four times as fast as one drive, and no downtime. 3.7.3. Disk Software In this section we will look at some issues related to disk drivers in general. First, consider how long it takes to read or write a disk block. The time required is determined by three factors: 1. The seek time (the time to move the arm to the proper cylinder). 2. The rotational delay (the time for the proper sector to rotate under the head). 3. The actual data transfer time. For most disks, the seek time dominates the other two times, so reducing the mean seek time can improve system performance substantially. Disk devices are prone to errors. Some kind of error check, a checksum or a cyclic redundancy check, is always recorded along with the data in each sector on a disk. Even the sector addresses recorded when the disk is formatted have check data. Floppy disk controller hardware can usually report when an error is detected, but the software must then decide what to do about it. Hard disk controllers often take on much of this burden. Particularly with hard disks, the transfer time for consecutive sectors within a track can be very fast. Thus reading more data than requested and caching it in memory can be very effective in speeding disk access. 3 3 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Disk Arm Scheduling Algorithms If the disk driver accepts requests one at a time and carries them out in that order, that is, First-Come, First-Served (FCFS), little can be done to optimize seek time. However, another strategy is possible when the disk is heavily loaded. It is likely that while the arm is seeking on behalf of one request, other disk requests may be generated by other processes. Many disk drivers maintain a table, indexed by cylinder number, with all pending requests for each cylinder chained together in a linked list headed by the table entries. [Page 282] Given this kind of data structure, we can improve upon the first-come, first-served scheduling algorithm. To see how, consider a disk with 40 cylinders.A request comes in to read a block on cylinder 11. While the seek to cylinder 11 is in progress, new requests come in for cylinders 1, 36, 16, 34, 9, and 12, in that order. They are entered into the table of pending requests, with a separate linked list for each cylinder. The requests are shown in Fig. 3-21. Figure 3-21. Shortest Seek First (SSF) disk scheduling algorithm. [View full size image] When the current request (for cylinder 11) is finished, the disk driver has a choice of which request to handle next. Using FCFS, it would go next to cylinder 1, then to 36, and so on. This algorithm would require arm motions of 10, 35, 20, 18, 25, and 3, respectively, for a total of 111 cylinders. Alternatively, it could always handle the closest request next, to minimize seek time. Given the requests of Fig. 3-21, the sequence is 12, 9, 16, 1, 34, and 36, as shown as the jagged line at the bottom of Fig. 3-21. With this sequence, the arm motions are 1, 3, 7, 15, 33, and 2, for a total of 61 cylinders. This algorithm, Shortest Seek First (SSF), cuts the total arm motion almost in half compared to FCFS. Unfortunately, SSF has a problem. Suppose that more requests keep coming in while the requests of Fig. 3-21 are being processed. For example, if, after going to cylinder 16, a new request for cylinder 8 is present, that request will have priority over cylinder 1. If a request for cylinder 13 then comes in, the arm will next go to 13, instead of 1. With a heavily loaded disk, the arm will tend to stay in the middle of the disk most of the time, so requests at either extreme will have to wait until a statistical fluctuation in the load causes there to be no requests near the middle. Requests far from the middle may get poor service. The goals of minimal response time and fairness are in conflict here. Tall buildings also have to deal with this trade-off. The problem of scheduling an elevator in a tall building is similar to that of scheduling a disk arm. Requests come in continuously calling the elevator to floors (cylinders) at random. The microprocessor running the elevator could easily keep track of the sequence in which customers pushed the call button and service them using FCFS. It could also use SSF. 4 4 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [Page 283] However, most elevators use a different algorithm to reconcile the conflicting goals of efficiency and fairness. They keep moving in the same direction until there are no more outstanding requests in that direction, then they switch directions. This algorithm, known both in the disk world and the elevator world as the elevator algorithm, requires the software to maintain 1 bit: the current direction bit, UP or DOWN. When a request finishes, the disk or elevator driver checks the bit. If it is UP, the arm or cabin is moved to the next highest pending request. If no requests are pending at higher positions, the direction bit is reversed. When the bit is set to DOWN, the move is to the next lowest requested position, if any. Figure 3-22 shows the elevator algorithm using the same seven requests as Fig. 3-21, assuming the direction bit was initially UP. The order in which the cylinders are serviced is 12, 16, 34, 36, 9, and 1, which yields arm motions of 1, 4, 18, 2, 27, and 8, for a total of 60 cylinders. In this case the elevator algorithm is slightly better than SSF, although it is usually worse. One nice property that the elevator algorithm has is that given any collection of requests, the upper bound on the total motion is fixed: it is just twice the number of cylinders. Figure 3-22. The elevator algorithm for scheduling disk requests. [View full size image] A slight modification of this algorithm that has a smaller variance in response times is to always scan in the same direction (Teory, 1972). When the highest numbered cylinder with a pending request has been serviced, the arm goes to the lowest-numbered cylinder with a pending request and then continues moving in an upward direction. In effect, the lowest-numbered cylinder is thought of as being just above the highest-numbered cylinder. Some disk controllers provide a way for the software to inspect the current sector number under the head. With such a controller, another optimization is possible. If two or more requests for the same cylinder are pending, the driver can issue a request for the sector that will pass under the head next. Note that when multiple tracks are present in a cylinder, consecutive requests can be for different tracks with no penalty. The controller can select any of its heads instantaneously, because head selection involves neither arm motion nor rotational delay. [Page 284] With a modern hard disk, the data transfer rate is so much faster than that of a floppy disk that some kind of automatic caching is necessary. Typically any request to read a sector will cause that sector and up to the rest of the current track to be read, depending upon how much space is available in the controller's cache memory. Current caches are often 8 MB or more. 5 5 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... returned and the disk is not usable Finally, MINIX 3 uses a u32_t variable to count addresses in bytes This limits the size of a partition to 4 GB However, the device structure used to record the base and size of a partition (defined in drivers/libdriver/driver.h on lines 10856 to 10858) uses u 64_ t numbers, and a 64 bit multiplication operation is used to calculate the size of the drive on (line 12688), and. .. 24- bit number, with 8 bits each for red, green, and blue A 768 x 10 24 color display with 24 bits per pixel requires 2 MB of RAM to hold the image 3 4 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com With a memory-mapped display, the keyboard is completely decoupled from the screen It may be interfaced via a serial or parallel port On every key action the CPU is interrupted, and. .. each card or writing and reading I/O ports to identify each card This is possible (and works better on newer IBM-type systems than on older ones), but it does not accommodate nonstandard I/O devices Also, probing I/O ports to identify one device sometimes can activate another device which seizes control and disables the system This method complicates the startup code for each device, and yet still does... storage capacity and reduced performance In the discussion in this section and the next, we will take as our model the AT-style hard disk driver, which is the default driver in the standard MINIX 3 distribution This is a versatile driver that handles hard disk controllers from the ones used in the earliest 80286 systems to modern EIDE (Extended Integrated Drive Electronics) controllers that handle gigabyte... smaller and the capacity is much larger than the 14- inch disks that were typical of the early 1970s when the winchester technology was developed [Page 291] The MINIX 3 AT-style hard disk driver is in at_wini.c (line 12100) This is a complicated driver for a sophisticated device, and there are several pages of macro definitions specifying controller registers, status bits and commands, data structures, and. .. the basic hardware MINIX 3 has been developed on and for newer systems with Pentium-class CPUs, but even among these there are differences For instance, the oldest Pentium systems use the 16-bit AT bus originally designed for the 80286 processor A feature of the AT bus is that it was cleverly designed so older 8-bit peripherals could still be used Later systems added a 32-bit PCI bus for peripherals,... model), by doing a seek to cylinder zero 13 14 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Do_transfer (line 128 14) does what its name implies, it assembles a command structure with all the byte values needed to request transfer of a chunk of data (possibly as many as 255 disk sectors), and then it calls com_out, which sends the command to the disk controller The data must... 3 Sector Number (0-7) Sector Number (0-7) 4 Cylinder Low (8-15) Cylinder Low (8-15) 5 Cylinder High (16-23) Cylinder High (16-23) 6 Select Drive/Head ( 24- 27) Select Drive/Head ( 24- 27) 7 Status Command (a) 7 6 5 4 3 2 1 0 1 LBA 1 D HS3 HS2 HS1 HS0 LBA: 0 = Cylinder/Head/Sector Mode 1 = Logical Block Addressing Mode D: 0 = master drive 15 16 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com... the registers which set up and execute a command As we mentioned in the overview section, the next receive operation normally should receive a notification indicating an interrupt If an alarm has been set and no interrupt occurs, the next message will be a SYN_ALARM In this case w_timeout line 13 046 is called What needs to be done depends on the current command in w_command The timeout might have been... operation, and w_command may have the value CMD_IDLE, meaning the disk completed its operation In that case there is nothing to do If the command does not complete and the operation is a read or write, it may help to reduce the size of I/O requests This is done in two steps, first reducing the maximum number of sectors that can be requested to 8, and then to 1 For all timeouts a message is printed and w_need_reset . the implementer of an operating system). The difference in data density between inner and outer tracks means a sacrifice in capacity, and more sophisticated systems exist. Floppy disk designs that rotate. Number (0-7) 4 Cylinder Low (8-15) Cylinder Low (8-15) 5 Cylinder High (16-23) Cylinder High (16-23) 6 Select Drive/Head ( 24- 27) Select Drive/Head ( 24- 27) 7 Status Command (a) 7 6 5 4 3 2 1 0 1. the device type. The first case is for /dev/null, and the action is to return immediately on a DEV_GATHER request or on a 4 4 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com DEV_SCATTER