Another key concept supported by virtually all operating systems is the file system. As noted before, the most important function of the operating system is to hide the peculiarities of the disks and other I/O devices and present the programmer with a nice, clean abstract model of device-independent files. System calls are obviously required to create files, remove files, read files, and write files. Before a file can be read, it must be located on the disk and opened, and after it has been read it should be closed, so calls are provided to do these things.
To provide a place to keep files, the majority of operating systems have the concept of a directory as a way of grouping files together. A student, for example, might have one directory for each course he or she is taking (for the programs needed for that course), another directory for his electronic mail, and still another directory for his World Wide Web home page. System calls are then required to create and remove directories. Calls are also provided to put an existing file in a directory, and to remove a file from a directory. Directory entries may be either files or other directories. This model also gives rise to a hierarchy-the file system - as shown in the following figure 1.
The process and file hierarchies both are organized as trees, but the similarity stops there. Process hierarchies generally are not very deep (more than three levels is unusual), whereas file hierarchies are commonly four, five, or even more levels deep. Process hierarchies are typically short-lived, usually minutes at most, whereas the directory hierarchy may exist for years. Ownership and protection also differ for processes and files. Normally, only a parent process may control or even access a child process, but mechanisms nearly always exist to allow files and directories to be read by a wider group than just the owner.
Every file within the directory hierarchy can be specified by giving its path name from the top of the directory hierarchy, the root directory. Such absolute path names consist of the list of directories that must be traversed from the root directory to get to the file, with slashes separating the components. In above figure 1, the path for file CS101 is /Faculty/Prof.Brown/Courses/CS101. The leading slash indicates that the path is absolute, that is, starting at the root directory. As an aside, in MS-DOS and Windows, the backslash (\) character is used as the separator instead of the slash (/) character, so the file path given above would be written as \Faculty\Prof.Brown\Courses\CS101. Throughout this blog we will normally use the UNIX convention for paths.
At every instant, each process has a current working directory, in which path names not beginning with a slash are looked for. As an example, in above figure 1, if /Faculty/Prof.Brown were the working directory, then use of the path name Courses/CS101 would yield the same file as the absolute path name given above. Processes can change their working directory by issuing a system call specifying the new working directory.
Before a file can be read or written, it must be opened, at which time the permissions are checked. If the access is allowed, the system returns a small integer called a file descriptor to use in subsequent operations. If the access is prohibited, an error code is returned.
Another important concept in UNIX is the mounted file system. Nearly all personal computers have one or more optical drives into which CO-ROMs and DVDs can be inserted. They almost always have USB ports, into which USB memory sticks (really, solid state disk drives) can be plugged, and some computers have floppy disks or external hard disks. To provide an elegant way to deal with these removable media UNIX allows the file system on a CD-ROM or DVD to be attached to the main tree. Consider the situation of following figure 2(a). Before the mount call, the root file system, on the hard disk, and a second file system, on a CDROM, are separate and unrelated.
However, the file system on the CD-ROM cannot be used, because there is no way to specify path names on it. UNIX does not allow path names to be prefixed by a drive name or number; that would be exactly the kind of device dependence that operating systems ought to eliminate. Instead, the mount system call allows the file system on the CD-ROM to be connected to the root file system wherever the program wants it to be. In the following figure 2(b) the file system on the CD-ROM has been mounted on directory b, therefore allowing access to files /b/x and /b/y. If directory b had contained any files they would not be accessible while the CD-ROM was mounted, since /b would refer to the root directory of the CD-ROM. (Not being able to access these files is not as serious as it at first seems: file systems are nearly always mounted on empty directories.) If a system contains multiple hard disks, they can all be mounted into a single tree as well.
Another important concept in UNIX is the special file. Special files are provided in order to make I/O devices look like files. That way, they can be read and written using the same system calls as are used for reading and writing files. Two kinds of special files exist: block special files and character special files. Block special files are used to model devices that comprise a collection of randomly addressable blocks, such as disks. By opening a block special file and reading, say, block 4, a program can directly access the fourth block on the device, without regard to the structure of the file system contained on it. Likewise, character special files are used to model printers, modems, and other devices that accept or output a character stream. By convention, the special files are kept in the /dev directory. For example, /dev/lp might be the printer (once called the line printer).
The last feature we will discuss in this overview is one that relates to both processes and files: pipes. A pipe is a sort of pseudofile that can be used to connect two processes, as shown in "Input/Output" figure. If processes A and B wish to talk using a pipe, they must set it up in advance. When process A wants to send data to process B, it writes on the pipe as though it were an output file. Actually, the implementation of a pipe is very much like that of a file. Process B can read the data by reading from the pipe as though it were an input file. Thus, communication between processes in UNIX looks very much like ordinary file reads and writes. Stronger yet, the only way a process can discover that the output file it is writing on is not really a file, but a pipe, is by making a special system call. File systems are very important. We will have much more to say about them in "FILE SYSTEMS" and also in "CASE STUDY1: LINUX" and "CASE STUDY 2: WINDOWS VISTA".
Tagsi/o devices, file system, process
- Error Handling
- EXAMPLE FILE SYSTEMS
- Defragmenting Disks
- File System Consistency
- File System Backups
- Implementing Directories
- FILE SYSTEM IMPLEMENTATION
- Backing Store
- The Readers and Writers Problem
- CLASSICAL IPC PROBLEMS
- Thread Scheduling
- Shortest Process Next
- When to Schedule
- Sleep and Wakeup
- Critical Regions
- INTERPROCESS COMMUNICATION / Race Conditions
- INTERPROCESS COMMUNICATION / Race Conditions
- Making Single-Threaded Code Multithreaded
- Pop-Up Threads
- Implementing Threads in the Kernel
- POSIX Threads
- Modeling Multiprogramming
- Process States
- Process Hierarchies
- Process Termination
- The Process Model
- PROCESSES AND THREADS
- METRIC UNITS / SUMMARY
- OUTLINE OF THE REST OF THIS BLOG
- The Model of Run Time
- Layered Systems
- OPERATING SYSTEM STRUCTURE
- The Windows Win32 API
- Miscellaneous System Calls
- System Calls for Directory Management
- System Calls for File Management
- Hard Disks
- Address Spaces
- OPERATING SYSTEM CONCEPTS - PROCESSES
- I/O Devices
- COMPUTER HARDWARE REVIEW
- The Operating System as a Resource Manager