Electrical computers and digital processing systems: multicomput – Distributed data processing
Reexamination Certificate
2000-09-29
2001-10-09
Beausoleil, Robert (Department: 2181)
Electrical computers and digital processing systems: multicomput
Distributed data processing
C709S203000, C710S120000, C710S005000, C711S112000
Reexamination Certificate
active
06301605
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to operating systems and, more specifically, to a distributed storage architecture of an operating system.
BACKGROUND OF THE INVENTION
An operating system is a large, complex piece of software whose primary function is the management of hardware and software resources of a data processing system such as processors, memory and storage. Storage management, in turn, involves the organization of storage devices, such as disks, into logical groupings to achieve various performance and availability characteristics. For example, the disks may be arranged to create individual volumes or concatenations of volumes, mirror sets or stripes of mirror sets, or even redundant arrays of independent disks (RAID). The data processing platform on which the operating system executes to provide such management functions typically includes a host computer coupled to a storage adapter or controller. The operating system functionally organizes this platform by, inter alia, invoking input/output (I/O) operations in support of software processes or applications executing on the computer.
A storage architecture of the operating system decomposes management of the storage devices into individual components and defines their functional operations with respect to the flow of information and control among them. The individual components include an I/O subsystem and a file system, each of which is generally independent of one another and interact according to interfaces defined by the architecture. The I/O subsystem provides an efficient mode of communication between the computer and the disks that allows programs and data to be entered into the memory of the computer for processing; the subsystem also enables the results obtained from computations of that information to be recorded on the disks.
The file system contains general knowledge of the organization of information on the storage devices and provides algorithms that implement properties/performance of the desired storage architecture. To that end, the file system is a high-level software entity comprising a collection of program modules, e.g., software drivers, that incorporate a command set for the storage devices/disks. Typically, the operating system implements a file system to logically organize the information as a hierarchical structure of files on the disks.
I/O processing is typically performed under the auspices of the file system in that applications typically interact with the file system to manipulate (i.e., read or write) the files. I/O subsystems, on the other hand, interact with disks at lower software levels by manipulating blocks of data. Accordingly, a single I/O transaction operation issued by an application to the file system may spawn into many I/O transfer operations between the I/O subsystem and disks; that is, there may be multiple data transfers between the lower-layer software entities and the actual hardware devices.
Requests to perform I/O transactions are generally serial in nature. Upon requesting data to be read from or written to a file, the application program typically suspends execution and the request is processed by the file system and I/O subsystem. The file system and I/O subsystem are composed of many layers of software driver code that is commonly referred to as an I/O stack.
FIG. 1
is a schematic block diagram of a conventional I/O stack
100
comprising a file system driver
102
, a logical volume driver
104
, a disk class driver
106
and device-specific drivers, such as small computer system interface (SCSI) port and miniport drivers
108
,
110
.
The organization of a file system and I/O subsystem within a hardware platform vary among conventional storage architectures.
FIG. 2A
is a block diagram of a traditional storage architecture
200
having a file system
202
and I/O subsystem
204
that are organized to execute entirely on a host computer
206
. In response to an I/O transaction request issued by an application, the host processor executes the software code of the file system and I/O subsystem needed to transfer data from disk to the host memory. In this architecture, the host processor actually executes the code of the I/O stack twice for the I/O transaction: once as the transaction descends the stack and again as the results of the transaction are returned to the application. Execution of I/O operations for this type of architecture clearly consumes significant computer resources.
To avoid such consumption of resources, some storage architectures alter the arrangement of their file systems and I/O subsystems.
FIG. 2B
illustrates a conventional RAID controller architecture
210
wherein the file system
212
is contained within the host computer
216
and the I/O subsystem
214
is distributed between the host computer and controller
218
. Most implementations of this architecture are configured to execute RAID-related operations by transferring discrete block-oriented requests between the file system and controller. When these requests complete, however, the host processor is notified by means of interrupts, i.e., events that change the normal flow of instruction execution by the host processor. For this type of architecture, there may be many interrupts associated with a single transaction; since each interrupt must be serviced by the host processor, this architecture results in inefficient use of the processor.
Other storage architectures provide their file systems and I/O subsystems entirely on the controller. The host computer
226
of
FIG. 2C
interacts with the controller
228
in accordance with a conventional client-server computing model
220
wherein the host computer (“client”) forwards each I/O transaction to the controller (“server”) typically across an interconnection such as a network; notably, all transactions are sent to the controller and none are serviced locally at the host computer. An example of such an architecture is described in U.S. Pat. No. 5,163,131 titled Parallel I/O Network File Server Architecture by Edward J. Row et al, issued on Nov. 10, 1992.
Row discloses a server-specific I/O architecture that is optimized for file operations of a Unix file server. The file server architecture comprises one or more network controllers, one or more file controllers, one or more storage processors, and a memory interconnected by a message passing bus and operating in parallel with the Unix host. Client requests for file operations are transmitted to a file controller which, independently of the Unix host, manages a virtual file system of a mass storage device coupled to the storage processors. Although this architecture relieves the host processor from I/O processing, it also adversely affects file system latency, i.e., the period of time between the issuance of an I/O transaction request by an application to the file system and the completion of that request by the file system.
In general, file system latency increases with an architecture having a file system that is remote from the processing platform on which the application executes; another example of such an architecture is described in U.S. Pat. No 5,463,772 titled Transparent Peripheral File Systems with On-board Compression, Decompression and Space Management by Bruce A. Thompson et al, issued on Oct. 31, 1995. Here, a peripheral file system is disclosed that may be embedded in a mass storage device, a lump in an interconnecting interface cable or on a smart interface card in the backplane of a host computer. Since Thompson discloses a file system that is remote from the host, file system latency is again affected. Latency of an I/O request is a determinative indication of overall file system performance and the present invention is directed to reducing file system latency.
In a conventional client-server computing environment, I/O capacity and storage management are also significant issues, particularly for the server. I/O capacity is defined as throughput at a certain latency, e.g., 500 megabits per second at a latency not to exceed 10 milliseconds. C
Arnott Randy Marc
Franklin Chris
Hoskins Timothy Lee
Juzsczak Chester
Luke Stanley
Adaptec, Inc.
Beausoleil Robert
Cesari and McKenna LLP
Phan Raymond N
LandOfFree
File array storage architecture having file system... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with File array storage architecture having file system..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and File array storage architecture having file system... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2617648