9.1 File Systems

Early operating systems had file systems that minimally extended a level of organization specified by a tray of punched cards or a reel of magnetic tape. The advent of disk-oriented operating systems (such as CP/M) introduced support for subdirectories and consistent, if limited, conventions for naming files stored on disk. Current operating systems build on those disk-oriented principles, adding features such as long file names of mixed case. These systems also provide graphical ways to view the catalogue of files by directory and subdirectory (also known as folders).

Operating systems intended for shared use extend these concepts with some means of designating individual and/or group "ownership" of directories and files, typically using a matrix of permissions that the system can match against the identity of the person, process, or program seeking access. Names of directories and files in Unix or Linux are always case-sensitive and case-preserving. These operating systems store ownership and access protection information in the directory data associated with every file. Some operating systems, especially those meant to accommodate multiuser databases, support shared access, whereby more than one process can modify a file using strategies that make explicit any conflicts or ambiguities arising from near-simultaneous updates.

Multiuser operating systems typically offer methods to limit the absolute amount of storage claimed by any one user. The storage requirements of directories themselves and any hidden pointers required to catalogue, point to, or link the disjointed portions of physically fragmented files are all tallied against the owner's storage quota. In all cases, the file system has to maintain a dynamic and comprehensive inventory of space allocation, marking regions of the disk as used when files grow and putting such regions back into some form of free list when files are deleted.

Many pieces of information may be specified when a new file is created, such as the file's name, owner, protections, access mode, and internal file organization. The system must apply and record such information, as well as assure access to the amount of storage requested, either up-front or as needed.

Clearly, the software components required to support a full-featured file system are not simple to implement. Such system software is usually defined in layers, with increasing levels of abstraction. The programmer can still use lower levels of routines as needed. Figure 9-2 depicts the basic layers in a Unix-like programming environment.

Figure 9-2. File system layers seen by a C program

graphics/09fig02.gif

9.1.1 Unix® I/O Software

For a Unix system, the appropriate device controllers and the requisite components in the operating system kernel manage physical data storage. Other parts of the operating system regulate access to storage devices and manage data storage at a logical level. A file will logically correspond to an idealized address space capable of growing to as many kibi-, mebi-, or gibibytes as may prove to be necessary.

Unix environments define I/O system calls such as creat and open to establish and access files, and read and write to move bytes of information from and into files. A particular operating system implementation may make such system calls available to a programmer using assembly language or a high-level language like C; an arrow in Figure 9-2 indicates this possible access.

The C programming language was initially defined without consideration for input and output, but has been accompanied by a library defining standard functions such as fopen to establish and access files, or fgets and fputs to move bytes of information from and into files. An operating system implementation may make such system calls available to a programmer, as indicated in Figure 9-2.

9.1.2 Linux® I/O Software

Linux supports some underlying types of file systems that differ from those historically associated with Unix. Nevertheless, the software layers shown in Figure 9-2 hide such differences, with the result being that the programming interface for Linux I/O is quite similar to that for Unix I/O. Unless specifically stated, the descriptions in this chapter apply to both operating system types.



ItaniumR Architecture for Programmers. Understanding 64-Bit Processors and EPIC Principles
ItaniumR Architecture for Programmers. Understanding 64-Bit Processors and EPIC Principles
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net