5.2.4: Device-Independent I/O Software

The device-independent code does most of the functionality, but not necessarily most of the code since there can be many drivers all doing essentially the same thing in slightly different ways due to slightly different controllers.

• Naming. Again an important O/S functionality. Must offer a consistent interface to the device drivers.
  • In Unix this is done by associating each device with a (special) file in the /dev directory.
  • The inodes for these files contain an indication that these are special files and also contain so called major and minor device numbers.
  • The major device number gives the number of the driver. (These numbers are rather ad hoc, they correspond to the position of the function pointer to the driver in a table of function pointers.)
  • The minor number indicates for which device (e.g., which scsi cdrom drive) the request is intended
  
  
• Protection. A wide range of possibilities are actually done in real systems. Including both extreme examples of everything is permitted and nothing is permitted (directly).
  • In ms-dos any process can write to any file. Presumably, our offensive nuclear missile launchers do not run dos.
  • In IBM and other mainframe OS's, normal processors do not access devices. Indeed the main CPU doesn't issue the I/O requests. Instead an I/O channel is used and the mainline constructs a channel program and tells the channel to invoke it.
  • Unix uses normal rwx bits on files in /dev (I don't believe x is used).
  
  
• Buffering is necessary since requests come in a size specified by the user and data is delivered in a size specified by the device.
  
  
• Enforce exclusive access for non-shared devices like tapes.

5.2.5: User-Space Software

A good deal of I/O code is actually executed in user space. Some is in library routines linked into user programs and some is in daemon processes.

• Some library routines are trivial and just move their arguments into the correct place (e.g., a specific register) and then issue a trap to the correct system call to do the real work.
  
  
• Some, notably standard I/O (stdio) in Unix, are definitely not trivial. For example consider the formatting of floating point numbers done in printf and the reverse operation done in scanf.
  
  
• Printing to a local printer is often performed in part by a regular program (lpr in Unix) and part by a daemon (lpd in Unix). The daemon might be started when the system boots or might be started on demand. I guess it is called a daemon because it is not under the control of any user. Does anyone know the reason.
  
  
• Printing uses spooling, i.e., the file to be printed is copied somewhere by lpr and then the daemon works with this copy. Mail uses a similar technique (but generally it is called queuing, not spooling).

Homework: 6, 7, 8.

5.3: Disks

The ideal storage device is

1. Fast
2. Big (in capacity)
3. Cheap
4. Impossible

Disks are big and cheap, but slow.

5.3.1: Disk Hardware

Show a real disk opened up and illustrate the components

• Platter
• Surface
• Head
• Track
• Sector
• Cylinder
• Seek time
• Rotational latency
• Transfer time

Overlapping I/O operations is important. Many controllers can do overlapped seeks, i.e. issue a seek to one disk while another is already seeking.

Despite what Tanenbaum says, modern disks cheat and do not have the same number of sectors on outer cylinders as on inner one. However, the disks have electronics and software (firmware) that hides the cheat and gives the illusion of the same number of sectors on all cylinders.

Again contrary to Tanenbaum, it is not true that when one head is reading from cylinder C, all the heads can read from cylinder C with no penalty.

Choice of block size

• We discussed this before when studying page size.
• Current commodity disk characteristics (not for laptops) result in about 15ms to transfer the first byte and 10K bytes per ms for subsequent bytes (if contiguous).
  • Rotation rate is 5400, 7600, or 10,000 RPM (15K just now available).
  • Recall that 6000 RPM is 100 rev/sec or one rev per 10ms. So half a rev (the average time for to rotate to a given point) is 5ms.
  • Transfer rates around 10MB/sec = 10KB/ms.
  • Seek time around 10ms.
• This favors large blocks, 100KB or more.
• But the internal fragmentation would be severe since many files are small.
• Multiple block sizes have been tried as have techniques to try to have consecutive blocks of a given file near each other.
• Typical block sizes are 4KB-8KB.

Homework: Consider a disk with an average seek time of 10ms, an average rotational latency of 5ms, and a transfer rate of 10MB/sec.

1. If the block size is 1KB, how long would it take to read a block?
2. If the block size is 100KB, how long would it take to read a block?
3. If the goal is to read 1K, a 1KB block size is better as the remaining 99KB are wasted. If the goal is to read 100KB, the 100KB block size is better since the 1KB block size needs 100 seeks and 100 rotational latencies. What is the minimum size request for which a disk with a 100KB block size would complete faster than one with a 1KB block size?

5.3.2: Disk Arm Scheduling Algorithms

These algorithms are relevant only if there are several I/O requests pending. For many PCs this is not the case. For most commercial applications, I/O is crucial.

1. FCFS (First Come First Served): Simple but has long delays.
   
   
2. Pick: Same as FCFS but pick up requests for cylinders that are passed on the way to the next FCFS request.
   
   
3. SSTF (Shortest Seek Time First): Greedy algorithm. Can starve requests for outer cylinders and almost always favors middle requests.
   
   
4. Scan (Look, Elevator): The method used by an old fashioned jukebox (remember ``Happy Days'') and by elevators. The disk arm proceeds in one direction picking up all requests until there are no more requests in this direction at which point it goes back the other direction. This favors requests in the middle, but can't starve any requests.
   
   
5. C-Scan (C-look, Circular Scan/Look): Similar to Scan but only service requests when moving in one direction. When going in the other direction, go directly to the furthest away request. This doesn't favor any spot on the disk. Indeed, it treats the cylinders as though they were a clock, i.e. after the highest numbered cylinder comes cylinder 0.
   
   
6. N-step Scan: This is what the natural implementation of Scan gives.
   • While the disk is servicing a Scan direction, the controller gathers up new requests and sorts them.
   • At the end of the current sweep, the new list becomes the next sweep.

Minimizing Rotational Latency

Use Scan, which is the same as C-Scan. Why?
Because the disk only rotates in one direction.

Homework: 9, 10.