Filing, File Systems, and Operating Systems

The last of the three fundamental storage network functions is filing. In general, filing's role is to organize how data is structured in a storage address space as well as to represent it to applications and users. In practice, two types of filing products are in the market: file systems and databases.

File systems are closely associated with operating systems and have very close interactions with them. Considering how much storage activity there can be within a system, it is imperative that the file system and operating system work very well together without errors.

In most cases, they appear to be part of the same product, but that does not have to be the case. It is possible to use file systems that are not part of the operating system as long as the operating system supports third-party file systems. Most modern operating systems do, including most UNIX systems, Windows server systems, and Linux.

Space Allocation

One way to understand the differences between filing systems (including databases) and operating systems is to separate them by the system functions they manage. Operating systems manage the sequence of processing events in the system. In other words, they schedule all work in the system and establish the proper environment for each task. Filing systems manage the placement of data in storage address spaces.

In general,

• Operating systems manage time

• Filing systems manage space

One of the primary responsibilities of the filing function is space allocation. This involves figuring out what storage blocks to use when new data is being written or when data is changed or updated, as well as what to do with blocks that might be freed when objects are changed or deleted. While storing functions perform the actual operations of reading and writing data, filing functions determine what those operations should be.

One of the challenges in space allocation is creating a system that provides consistent performance over an extended period of time as data objects are created, updated, and deleted.

In order to achieve consistent performance, the filing system spreads data over the storage address space, providing a level of fairness to all data and its associated applications.

Filing's Role in Access Control and Security

Another key role of filing is access control. Filing systems often have attributes or access control lists (ACLs) that determine who has the authority to access data objects. To date, storing-level processes do not have the ability to provide access control, as storing level processes have no contextual information about data objects.

NOTE

DAS storing products never had to have access control capabilities, because all security functions were provided by the filing system and other system security functions. However, with SANs, it has become necessary for storage subsystems to provide some amount of access control to protect data resources. One storage technology used for access control is called LUN masking, and it is described in Chapter 5, "Storage Subsystems." Access controls for storage is an area that undoubtedly will see a great deal of development in the years to come.

File I/O

As described previously, storing functions work with storage address spaces made up of contiguous, fixed-length block locations. To maintain performance expectations, filing systems logically fragment this neat and orderly structure by scattering data objects throughout the address space. Fortunately, the details of this data scattering are masked from users and applications by the file system.

File systems provide friendlier and more intuitive structures for accessing data, such as a directory tree and filenames. Applications are developed to access data through these structures using published interfaces that are easily invoked in the application's code. This type of data access is called file I/O.

While applications are abstracted from storing-level details, they know everything about the byte structure within their data files. For example, the header information in a file might be 100 bytes and the data might be 2000 bytes. Applications today have many different types of data within their files, and it is essential that they are able to access the various discrete sections of files efficiently and accurately.

Therefore, file systems allow applications to locate data within the file by its byte location or byte range within the file. Byte ranges can be expressed by the number of bytes from the beginning or end of a file as well as by offsets of bytes from these locations. For example, an application might issue a request to read 50 bytes of a file starting at the 50th byte, as shown in Figure 2-4.

Figure 2-4. An Application Accesses Bytes 50 to 99 in a File

The file system bears the responsibility of converting these byte-range requests to detailed storing data access operations.

File Systems and Storing Applications

File systems contain the mappings of data objects into storing address spaces. This mapping function might also include the ability to translate file byte range requests into storing requests. Notice that while the byte range request might be for contiguous bytes, the lower-level block storing addresses are probably not contiguous.

So, a question arises: Why aren't file systems considered storing applications? The reason is because I said so, and it's my analysis! There has to be a separating point somewhere, and this is where I drew the line. Mapping a data object to a bunch of storage addresses does not involve storing processes by my way of thinking.

File systems make use of lower-level storing interfaces and functions that are provided by the operating system. The operating system kernel passes storage I/O requests to the proper storage device drivers that formulate the I/O requests into storing commands that are transferred to storage over a bus or network. The file system knows absolutely nothing about storing commands or devices; it only knows about a flat storing address spaceand what files are stuffed into which blocks within that storage address space.

This file system perspective of storage is the rationale behind using the term storage address space as a generalization for the wide variety of disks, disk partitions, volumes, and virtual storage.