System for granting bandwidth for real time processes and assigning bandwidth for non-real time processes while being forced to periodically re-arbitrate for new assigned bandwidth

A method and apparatus for coordinating access to a storage system in a real time processing system is disclosed. In an apparatus including a file server, a storage system, a real time process, and a non-real time process, an apparatus and method is disclosed for coordinating accesses to the storage system, the method includes the steps of: 1) computing an available data rate from a peak bandwidth data transfer rate for the storage system, 2) receiving a first access request from the real time process, the first access request including a request for a requested data rate, 3) granting the first access request if the requested data rate is less than or equal to the available data rate, and 4) allowing the real time process to directly access the storage system at the requested data rate. In addition, the method of the present invention includes the steps of: 1) receiving a second access request from the non-real time process, the second access request including information indicating an identity of a desired file, 2) assigning an assigned data rate to the non-real-time process, the assigned data rate being less than or equal to the available data rate, and 3) allowing the non-real time process to directly access the storage system at the assigned data rate.

BACKGROUND OF THE INVENTION 
1. Field of the Invention 
The present invention relates to the field of real time computer systems, 
and to a method and apparatus for coordinating access to a storage system 
by a mix of real time and non-real time processes of the real time 
computer system. 
2. Background Art 
Real time operating systems are well known in the prior art. These 
operating systems are typically multi-tasking preemptive operating systems 
providing low level support for system or client real time processes. Real 
time processes are those requiring some minimal level of processing time 
or input/output (I/O) data transfers over a given time slice. Real time 
processes often require a particular minimal bit rate delivery of data or 
I/O bandwidth of the available processing or input/output (I/O) capacity. 
Non-real time processes are those not requiring a minimal bit rate or I/O 
bandwidth. Non-real time processes typically do not suffer performance 
failures if their processing is interrupted for a period of time. Real 
time processes are sensitive to such system interruptions. 
An example of a system in which interruptions in the delivery of data 
produce unacceptable results is a video file system in a video server used 
for on-demand delivery of full length video programs. In such a system, 
hundreds of full length videos are stored in digital form in a 
multi-terabyte data storage system. Video data is retrieved in real time 
at a customer's request, and delivered via a communications network to the 
customer for viewing. In this type of system, interruptions in the 
continuous flow of video data from the real time system to the customer or 
client cause "blips" or other unacceptable deterioration in the quality of 
the video image being delivered. To deliver a satisfactory product to the 
end-user, such interruptions must be avoided. 
Real time processes, such as a video server, require a certain amount of 
I/O subsystem resources (e.g. disk bandwidth). There are two ways used in 
the prior art for handling these real time processes. 
The first prior art method for supporting real time processes is the use of 
an operating system that supports scheduling priorities. In this prior art 
implementation, a real time process running on top of an operating system 
that supports scheduling priorities gives itself a scheduling priority. 
The operating system uses the scheduling priority when scheduling central 
processing unit (CPU) time and when issuing I/O requests to an I/O device 
(e.g. a mass storage device or storage subsystem such as a disk drive or 
array of disk drives) for the real time process. This prior art 
implementation allows real time and non-real time processes to co-exist; 
however, such operating systems cannot always guarantee that the minimum 
I/O requirements of the real time process are met. In particular, the CPU 
scheduler may not be perfectly tuned to the needs of a particular real 
time process. Further, such operating systems are not always available. 
The second prior art method for supporting real time processes is the use 
of a single I/O process for centralizing the scheduling of I/O requests to 
an I/O device or subsystem. Referring to FIG. 6, a server 120 is shown to 
contain a single centralized I/O process 128 for scheduling and handling 
real time I/O requests to an I/O device 130 from a plurality of client 
systems or processes 126. The centralized I/O process 128 is able to 
coordinate all accesses to the I/O device 130 and all accesses to the I/O 
device 130 are made through the centralized process 128. This approach 
allows the centralized I/O process 128 to tightly control the scheduling 
of accesses to the I/O device 130 by assigning a time slice to each client 
126. The problem with this approach is that both real time and non-real 
time processes cannot be accommodated efficiently. Also, a central 
scheduling implementation does not scale well. As the number of processes 
increases, the amount of overhead performed by the scheduling mechanism 
rapidly increases. Hence, the scheduler quickly becomes a system 
bottleneck. 
It would be advantageous to implement a system in which a real-time process 
could control the bit rate of the delivery of a stream of real time data. 
It would also be advantageous to allow both real time and non-real time 
processes to be serviced according to their respective processing needs. 
It would be further advantageous to provide such a system that was 
independent of a particular operating system or system hardware platform. 
These characteristics are not present in prior art computer systems. 
U.S. Pat. No. 5,278,838 issued to Ng et al. discloses a method for 
rebuilding lost data in a redundant array data storage system (RAID) 
system while reducing interference with normal data recovery and storage 
operations. 
U.S. Pat. No. 5,315,602 issued to Noya et al. discloses a system for 
reducing the number of I/O requests required to write data in a RAID 
system. 
U.S. Pat. No. 5,305,326 issued to Solomon et al. discloses a method for 
handling reconstruction of data after a power failure, for example after a 
power failure of an I/O processor in a RAID system. 
U.S. Pat. No. 5,303,244 issued to Watson discloses a method for mapping 
logical RAID storage arrays to physical disk drives. 
U.S. Pat. No. 5,235,601 issued to Stallmo et al. discloses a method for 
restoring valid data in a RAID system after a write failure caused by a 
storage unit fault. 
U.S. Pat. No. 5,233,618 issued to Glider et al. discloses a method and 
apparatus for detecting and reconstructing incorrectly routed data, for 
detecting when a failure in writing a block of data has occurred, and for 
reconstructing the lost data. 
U.S. Pat. No. 5,287,462 issued to Jibbe et al. discloses an apparatus for 
coupling a host bus with a number of storage array busses in a RAID 
system. 
U.S. Pat. No. 5,124,987 issued to Milligan et al. discloses a disk drive 
array in which updates of redundancy data are eliminated by writing 
modified "virtual track instances" into logical tracks of the disks 
comprising a redundancy group. 
U.S. Pat. No. 5,088,081 issued to Farr discloses a RAID system in which 
reconstructed data from a bad data block are stored on a "reserve disk." 
U.S. Pat. No. 4,761,785 issued to Clark et al. discloses a storage 
management system in which parity blocks are distributed among a set of 
storage devices instead of being stored in a single storage device. 
Co-pending U.S. patent application Ser. No. 08/312,509 filed Sep. 26, 1994 
now U.S. Pat. No. 5,623,595 discloses a method and apparatus for providing 
transparent, real-time reconstruction of corrupted data from a redundant 
array of storage units. 
Thus, a better mechanism for coordinating access to a storage system in a 
real time environment is needed. 
SUMMARY OF THE INVENTION 
The present invention comprises a method and apparatus for coordinating 
access to a storage system in a real time processing system. In an 
apparatus including a file server and a storage system, an apparatus and 
method is disclosed for coordinating access to the storage system. The 
method includes the steps of: 1) computing an available data rate for the 
storage system, 2) receiving a first access request from a real time 
process, the first access request including a request for a requested data 
rate, 3) granting the first access request if the requested data rate is 
less than or equal to the available data rate, and 4) allowing the real 
time process to directly access the storage system at the requested data 
rate. The method of the present invention includes the step of deriving an 
updated available data rate based upon the available data rate and the 
requested data rate. In addition, the method of the present invention 
includes the steps of: 1) receiving a second access request from a 
non-real time process, 2) assigning an assigned data rate to the 
non-real-time process, the assigned data rate being at least a portion of 
the updated available data rate, and 3) allowing the non-real time process 
to directly access the storage system at the assigned data rate. 
The present invention is particularly suited to applications in which data 
is retrieved from a storage system using data striping for better load 
balancing; however, the benefits of the present invention are realized 
even if such a storage system is not used. The system of the present 
invention thus delivers data at a consistent rate regardless of whether 
real time or non-real time processes are executing. 
It is an advantage of the present invention that a real time process can 
control the bit rate of the delivery of a stream of real time data. It is 
a further advantage of the present invention that both real time and 
non-real time processes can be serviced according to their respective 
processing needs. It is a further advantage of the present invention that 
such a system is independent of a particular operating system or system 
hardware platform. These and other advantages of the present invention are 
described in detail in the following detailed description of the preferred 
embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION 
The present invention comprises a method and apparatus for coordinating 
access to a storage system in a real time processing system. In the 
following detailed description, numerous specific details are set forth in 
order to provide a more thorough understanding of the present invention. 
It will be apparent, however, to one skilled in the art, that the present 
invention may be practiced without these specific details. In other 
instances, well-known features have not been described in detail in order 
not to unnecessarily obscure the present invention. 
FIG. 1 illustrates a typical data processing system upon which one 
embodiment of the present invention is implemented. It will be apparent to 
those of ordinary skill in the art, however that other alternative systems 
of various system architectures may also be used. The data processing 
system illustrated in FIG. 1 includes a bus or other internal 
communication means 101 for communicating information, and a processor 102 
coupled to the bus 101 for processing information. The system further 
comprises a random access memory (RAM) or other volatile storage device 
104 (referred to as main memory), coupled to bus 101 for storing 
information and instructions to be executed by processor 102. Main memory 
104 also may be used for storing temporary variables or other intermediate 
information during execution of instructions by processor 102. The system 
also comprises a read only memory (ROM) and/or static storage device 106 
coupled to bus 101 for storing static information and instructions for 
processor 102, and a data storage device 107 such as a magnetic disk or 
optical disk and its corresponding disk drive. Data storage device 107 is 
coupled to bus 101 for storing information and instructions. The system 
may further be coupled to a display device 121, such as a cathode ray tube 
(CRT) or a liquid crystal display (LCD) coupled to bus 101 through bus 103 
for displaying information to a computer user. An alphanumeric input 
device 122, including alphanumeric and other keys, may also be coupled to 
bus 101 through bus 103 for communicating information and command 
selections to processor 102. An additional user input device is cursor 
control 123, such as a mouse, a trackball, stylus, or cursor direction 
keys coupled to bus 101 through bus 103 for communicating direction 
information and command selections to processor 102, and for controlling 
cursor movement on display device 121. Another device which may optionally 
be coupled to bus 101 through bus 103 is a hard copy device 124 which may 
be used for printing instructions, data, or other information on a medium 
such as paper, film, or similar types of media. In the preferred 
embodiment, a communication device 125 is coupled to bus 101 through bus 
103 for use in accessing other nodes of a distributed system via a 
network. This communication device 125 may include any of a number of 
commercially available networking peripheral devices such as those used 
for coupling to an Ethernet, token ring, Internet, or wide area network. 
Note that any or all of the components of the system illustrated in FIG. 1 
and associated hardware may be used in various embodiments of the present 
invention; however, it will be appreciated by those of ordinary skill in 
the art that any configuration of the system may be used for various 
purposes according to the particular implementation. In one embodiment of 
the present invention, the data processing system illustrated in FIG. 1 is 
an IBM.RTM. compatible personal computer or a Sun.RTM. SC Workstation. 
Processor 102 may be one of the 80X86 compatible microprocessors such as 
the 80486 or PENTIUM.RTM. brand microprocessors manufactured by INTEL.RTM. 
Corporation of Santa Clara, Calif. 
The software implementing the present invention can be stored in main 
memory 104, mass storage device 107, or other storage medium locally 
accessible to processor 102. Other storage media may include floppy disk 
drives, memory cards, flash memory, or CD-ROM drives. It will be apparent 
to those of ordinary skill in the art that the methods and processes 
described herein can be implemented as software stored in main memory 104 
or read only memory 106 and executed by processor 102. This software may 
also be resident on an article of manufacture comprising a computer 
readable medium 108 having computer readable program code embodied therein 
and being readable by the mass storage device 107 and for causing the 
processor 102 to coordinate accesses to a storage system in accordance 
with the teachings herein. 
Dynamic I/O Bandwidth Allocation 
Referring to FIG. 2, the server 200 of the preferred embodiment can 
accommodate a plurality of real time processes 215, and non-real time 
processes 216 executing therein. Server 200 is shown coupled to a disk 
subsystem 310 comprised of a disk controller 206 and disk storage 210. 
Server 200 is also coupled to a plurality of real time clients 220. In 
this typical configuration of processes, real time processes 215 require a 
steady stream of real time data at a fixed data rate across communication 
lines 222 and 224 to feed their real time clients 220. Conversely, 
non-real time processes 216 do not have such a data rate requirement. Such 
non-real time processes include copy operations, loading operations, or 
back-up processes. 
The real time processes 215 correspond to the real time clients 220. Server 
200 also includes a file server 205, which is used by the plurality of 
processes 215 and 216 for processing I/O bit rate requests from the 
plurality of real time processes 215 and to assign an I/O bit rate for 
each of the plurality of processes 215 and 216. These I/O bit rate 
requests and corresponding I/O bit rate assignments are performed between 
file server 205 and the plurality of processes 215 and 216 on data path 
230 as shown in FIG. 2. The major function of file server 205 is to 
coordinate access to the disk subsystem 310 by the processes 215 and 216. 
Once a process 215 or 216 obtains an I/O bit rate assignment from the file 
server 205, the process 215 or 216 directly accesses the disk controller 
206 on data path 231. Note that this access is direct to the storage 
subsystem 310 and bypasses the file server 205. It is possible that 
collisions may occur when multiple processes 215 or 216 try to access the 
storage subsystem 310 at the same time. However statistically, this type 
of collision does not occur frequently. The file server 205 allocates, if 
possible, the data rate requirements of the real time processes 215 and 
allocates reasonable I/O bit rates to the non-real time processes 216 
given the I/O bandwidth limitations of the storage subsystem 310. It is 
the functionality of the present invention that makes this difficult task 
possible. 
Referring now to FIG. 3, the protocol of the transactions between the file 
server 205 and real time processes 215 and non-real time processes 216 is 
illustrated. Both real time processes 215 and non-real time processes 216 
compete for usage of the disk subsystem 310. File server 205 manages the 
I/O bandwidth provided by disk subsystem 310. Every particular computer 
system configuration has a peak I/O bandwidth which represents the maximum 
output provided by the storage subsystem. Although a data striped disk 
subsystem, for example, balances the load across a plurality of disk 
units, there is still a peak I/O bandwidth that the storage subsystem 
cannot exceed without causing interruptions in the data provided to the 
processes 215 and 216. 
The peak bandwidth of a particular system is determined by way of 
conventional testing and stored by file server 205 in a variable 
identified as BW.sub.-- Max. This value represents the maximum or optimum 
I/O data rate at which data can be delivered by the storage subsystem. The 
optimum I/O data rate will vary depending on how a particular system is 
configured; however, the optimum I/O data rate for a particular system can 
be pre-determined or easily computed. A variable identified as BW.sub.-- 
Available is initialized with the BW.sub.-- Max optimum I/O data rate 
value. The BW.sub.-- Available value represents the currently available 
(i.e. unallocated) I/O bandwidth for the storage subsystem. This value 
will change as processes begin to use the storage subsystem. 
In FIG. 3, a file and data rate request is received by file server 205 from 
real time process 215. This request includes a requested I/O data rate or 
I/O bit rate at which the real time process 215 would like to receive the 
data from the requested file. This client requested data rate is 
identified as BW.sub.-- Req. The file server 205 computes the difference 
between the client requested data rate (BW.sub.-- Req) and the available 
data rate (BW.sub.-- Available). The BW.sub.-- Req value is subtracted 
from the BW.sub.-- Available value. If the result is positive, the client 
request is satisfied and the handle to the requested file is delivered to 
the real time process 215 along with the assigned I/O data rate. In this 
case, the assigned I/O data rate is the same as the requested data rate. 
The result is stored back in the BW.sub.-- Available variable as an 
updated available data rate (BW.sub.-- Available=BW.sub.-- 
Available-BW.sub.-- Req). If the result is negative, the client request 
cannot be granted. In this case, the client request is denied. In an 
alternative embodiment, the process 215 can be offered a reduced I/O data 
rate or assigned an I/O data rate which is smaller than the rate 
requested. If the process 215 accepts the reduced rate, the client request 
succeeds and the assigned I/O data rate, at the reduced rate, is granted 
to the client. The BW.sub.-- Available value is updated to account for the 
bandwidth consumed at the reduced rate (BW.sub.-- Available=BW.sub.-- 
Available-reduced rate). The file handle of the requested file is 
delivered to the process 215. Once the real time process 215 has obtained 
a file handle and assigned I/O data rate from the file server 205, the 
real time process 215 directly accesses the disk subsystem 310 using the 
file handle obtained from the file server 205. 
Referring still to FIG. 3, the protocol between the non-real time processes 
216 and file server 205 is illustrated. The transaction between the 
nonreal time processes and the file server 205 does not need to specify a 
particular data rate as is the case with a real time process 215. Instead, 
the non-real time process 216 merely requests a particular identified file 
from file server 205. The file server 205 returns a handle to the 
requested file, if possible, and assigns the non-real time process 216 a 
computed (i.e. assigned) data rate (BW.sub.-- Assigned), which represents 
a portion of the available data rate (BW.sub.-- Available). This assigned 
data rate can be computed in a number of ways. In the preferred 
embodiment, the non-real time process 216 is given an assigned data rate 
that represents some percentage (e.g. 10%) of the available I/O bandwidth, 
BW.sub.-- Available (for example, BW.sub.-- Assigned=BW.sub.-- 
Available*0.10). It is important to prevent a non-real time process 216 
from consuming all of the available I/O bandwidth thereby causing a 
subsequent request from a real time process 215 to fail. Depending upon a 
particular system configuration and usage, the assigned data rate for a 
non-real time process 216 can be some other percentage or portion of the 
available I/O bandwidth. Alternatively, the assigned data rate for a 
non-real time process 216 can be some fixed value less than the available 
I/O bandwidth or some fixed offset from the available I/O bandwidth. It 
will be apparent to those of ordinary skill in the art that other 
equivalent computations of the assigned I/O data rate for non-real time 
processes 216 can be implemented. Once the non-real time process 216 has 
obtained a file handle and assigned I/O data rate from the file server 
205, the non-real time process 216 directly accesses the disk subsystem 
310 at the assigned I/O data rate using the file handle obtained from the 
file server 205. Also, the BW.sub.-- Available value is updated to account 
for the bandwidth consumed at the assigned rate (BW.sub.-- 
Available=BW.sub.-- Available-BW.sub.-- Assigned). 
In order to prevent the non-real time process 216 from dominating the 
available I/O bandwidth, the file server 205 forces the non-real time 
process 216 to re-arbitrate the assigned I/O data rate after the non-real 
time process 216 has had access to the requested file at the assigned I/O 
data rate for some pre-defined time period (i.e. time slice). When this 
time slice has expired, the non-real time process 216 must again request 
the file server 205 for access to the desired file and again be assigned 
an I/O data rate by the file server 205. Because other clients may have 
requested access to the disk subsystem 310 or terminated their access to 
the disk subsystem 310 while the non-real time process 216 has been 
consuming bandwidth during its time slice, the newly assigned data rate 
for the non-real time process 216 may not be the same as the data rate 
assigned in the previous time slice. Thus, the I/O bandwidth used by 
non-real time processes 216 is dynamically re-adjusted as the non-real 
time processes 216 iteratively re-request the desired file from file 
server 205. The BW.sub.-- Available value is correspondingly updated to 
account for the newly assigned data rate by adding the previously assigned 
date rate back into the available bandwidth value and then reducing the 
available bandwidth by the newly assigned data rate (BW.sub.-- 
Available=BW.sub.-- Available+BW.sub.-- Assigned (previous); BW.sub.-- 
Available=BW.sub.-- Available-BW.sub.-- Assigned(new)). 
Referring now to FIG. 4, the processing logic used by the file server 205 
and a real time process 215 is illustrated. In block 410, a real time 
process 215 makes a request to the file server 205 for a specified file 
and a requested I/O data rate. If the requested file cannot be opened 
(processing path 419), processing is terminated through the End block 
shown in FIG. 4. In this case, the requested file is currently unavailable 
to the requesting client. If the file server 205 can provide the requested 
file, processing path 415 is taken and block 412 is executed. If the 
requested I/O data rate, BW.sub.-- Req, is larger than the available 
bandwidth, BW.sub.-- Available, the requested I/O data rate cannot be 
provided (processing path 413). In this case, either processing is 
terminated at the End block or, in an alternative embodiment, a reduced 
I/O data rate is offered to the process 215 (processing block 417). If the 
reduced I/O data rate is accepted by the process 215 or if the server can 
provide the requested I/O data rate (BW.sub.-- Req is smaller than or 
equal to the available bandwidth, BW.sub.-- Available), processing block 
416 is executed. The file server 205 returns a file handle to the process 
215 and returns the assigned data rate (i.e. the requested rate or the 
reduced rate) to the process 215 (block 416). The BW.sub.-- Available 
value is updated to account for the bandwidth consumed at the assigned 
rate (BW.sub.-- Available=BW.sub.-- Available-BW.sub.-- Assigned). The 
real time process 215 uses the file handle to directly access the storage 
subsystem 310 to perform input/output with the specified file at the 
assigned I/O data rate until the process is finished with the file (block 
418). When finished, the real time process 215 closes the file (block 
420). The file server 205 releases the previously assigned I/O bandwidth 
(block 422). Bandwidth is released by adding the previously assigned and 
now relinquished I/O bandwidth back into the available bandwidth 
(BW.sub.-- Available=BW.sub.-- Available+BW.sub.-- Assigned). Processing 
for the real time process 215 terminates through the End block shown in 
FIG. 4. 
It is important to note that the present invention assigns I/O data rates 
for each process, not time slices for each process as in the prior art 
systems. This is important because this distinction allows the present 
invention to effectively accommodate real time processes and non-real time 
processes in their access to a storage subsystem, wherein each process 
whether real time or non-real time can receive its own assigned I/O data 
rate. This feature allows the present invention to fully utilize the I/O 
bandwidth available in a particular storage subsystem. The present 
invention is advantageous also because it eliminates the need to precisely 
schedule all accesses. In this implementation, much less coordination and 
synchronization is needed. 
Referring now to FIG. 5, the processing logic used by the file server 205 
and a non-real time process 216 is illustrated. In block 510, a non-real 
time process 216 makes a request to the file server 205 for a requested 
file. If the requested file cannot be opened (processing path 513), 
processing is terminated through the End block shown in FIG. 5. In this 
case, the requested file is currently unavailable to the requesting 
client. If the file server 205 can provide the requested file, processing 
path 514 is taken and block 516 is executed. The file server 205 returns a 
file handle of the requested file and dynamically assigns an assigned I/O 
data rate to the non-real time process 216 (block 516) as described above. 
The BW.sub.-- Available value is updated to account for the bandwidth 
consumed at the assigned rate (BW.sub.-- Available=BW.sub.-- 
Available-BW.sub.-- Assigned). The non-real time process 216 performs 
input/output directly with the storage subsystem 310 using the file handle 
at the assigned I/O data rate until an execution time slice expires (block 
518). If the non-real time process 216 has not completed its I/O with the 
requested file (path 523), the non-real time process 216 again issues a 
request to the file server 205 for access to the file and the file server 
205 assigns a new I/O data rate to the non-real time process (block 519) 
for the next time slice. The BW.sub.-- Available value is correspondingly 
updated to account for the new assigned data rate by adding the previous 
assigned date rate back into the available bandwidth value and then 
reducing the available bandwidth by the newly assigned data rate 
(BW.sub.-- Available=BW.sub.-- Available+BW.sub.-- Assigned (previous); 
BW.sub.-- Available=BW.sub.-- Available-BW.sub.-- Assigned(new)). Block 
518 is executed for the next time slice at the newly assigned data rate. 
Processing continues in this loop with dynamically assigned I/O data rates 
until the non-real time process 216 file input/output has been completed. 
When finished (path 525), the non-real time process 216 closes the file 
(block 520). The file server 205 releases the previously allocated 
bandwidth (block 522). Bandwidth is released by adding the previously 
assigned and now relinquished bandwidth back into the available bandwidth 
(BW.sub.-- Available=BW.sub.-- Available+BW.sub.-- Assigned). Processing 
for the non-real time process 216 then terminates through the End block as 
shown in FIG. 5. 
In the preferred embodiment of the present invention, a disk array 
configuration with data striping is used to facilitate a dynamic I/O 
bandwidth allocation protocol. Data striping ensures that an equal load is 
applied across all disks. Using this protocol as described herein, a real 
time process can issue requests to the disk array subsystem at a 
pre-allocated bit rate and be guaranteed that bit rate. This capability is 
especially useful for real time applications where a relatively constant 
bit rate is needed, such as video or audio data applications. Because a 
data striped disk subsystem supports a high degree of predictability in 
the rate at which data can be returned, the dynamic I/O bandwidth 
allocation of a specified or enforced data rate is more easily 
implemented. It will be apparent to those of ordinary skill in the art, 
however, that the present invention can also be used in system 
configurations not having a multiple disk array. 
Typical data striping embodiments use a redundant disk array subsystem or 
RAID system. One such RAID system is disclosed in the above referenced 
co-pending patent application assigned to the same assignee as the present 
invention. Other prior art RAID systems are cited above. Because a RAID 
system guarantees load balancing across all disks of the disk array, a 
real time RAID system guarantees a predictable performance level. 
Thus, a method and apparatus for coordinating access to a storage system by 
a mix of real time and non-real time processes of the real time computer 
system is disclosed. Although the present invention has been described 
with respect to specific examples and subsystems, it will be apparent to 
those of ordinary skill in the art that the invention is not limited to 
these specific examples or subsystems but extends to other embodiments as 
well. The present invention includes all of these other embodiments as 
specified in the claims that follow.