5.2.4: Device-Independent I/O Software

Most of the functionality. But not necessarily most of the code since there can be many drivers all doing essentially the same thing is slightely different way 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.)

• 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 int the corrct place (e.g. registers) and then issue a trap to the correct system call.
• Some, notably standard-IO (stdio) in Unix, are definitely not trivial. For example consider the formatting of floating point numbers done in printf and the reverse in scanf.
• Printing to a local printer is often in part by a regular program (lpr in Unix) and part by a deamon (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.
• Pringing 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 not called spooling but queuing).

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. Often the controller ``cover for them'' and protect the lie.

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.