The Disk object simulates the behavior of a real disk. The disk has only a single platter, with multiple tracks containing individual sectors. Each track contains the same number of sectors, and blocks are uniquely identified by their sector number. As with a real disk, the OS initiates operations to read or write a specific sector, and a later interrupt indicates when the operation has actually completed. The Nachos disk allows only one pending operation at a time; the OS may initiate new operations only when the device is idle. Note that it is the responsibility of the OS to insure that new requests are not issued while the disk is busy servicing an earlier request.
In order to simulate typical delays in accessing a disk, the Nachos Disk object dynamically varies the time between the initiation of an I/O operation and its corresponding I/O complete interrupt. The actual delay depends on how long it takes to move the disk head from its previous location to the new track, as well as the rotational delay encountered waiting for the desired block to rotate under the read/write head.
The simulated disk contains NumTracks (32) tracks, each containing SectorsPerTrack (32) sectors. Individual sectors are SectorSize (128) bytes in size. In addition, Disk contains a ``track buffer'' cache. Immediately after seeking to a new track, the disk starts reading sectors, placing them in the track buffer. That way, a subsequent read request may find the data already in the cache reducing access latency.
The Disk object supports the following operations:
If the file already exists, Nachos reads the first 4 bytes to verify that they contain the expected Nachos ``magic number,'' terminating if the check fails. Note that by default the contents of a Nachos disk is preserved across multiple Nachos sessions, allowing users to create a Nachos file in one session, and read it in another. However, if the disk contains a file system, and the file system is left in a corrupted state by a previous Nachos session, subsequent Nachos invocations are likely run into problems if they don't first verify that the filesystem data structures are logically consistent.
The last two constructor arguments are used to provide an ``I/O complete'' interrupt mechanism. Specifically, the Nachos machine signals the completion of a Disk operation (e.g., read or write) by invoking the procedure callWhenDone, passing it an argument of callArg. As shown below, the SynchDisk object uses this routine to wake up a thread that has been suspended while waiting for I/O to complete.
Note that this operations returns immediately, before the transfer actually takes place. ReadRequest schedules an interrupt to take place sometime in the future, after a time roughly dependent on the seek distance needed to complete the operation. Only after the interrupt takes place is it correct to start using the data.