This application is based upon and claims the benefit of priority from corresponding Japanese Patent Application No. 2008-328953, filed Dec. 25, 2008, the entire contents of which are incorporated herein by reference.
1. Field of the Invention
The present invention relates to an image forming apparatus having an operating system (OS) and a Redundant Array of Inexpensive/Independent Disks (RAID) control unit, and relates to an access request arbitration method for a RAID control unit.
2. Description of the Related Art
In a RAID system, a plurality of hard disk drives (HDDs) can be configured to appear as a single drive to an OS. This virtual single drive may comprise a plurality of logical drives. For example, a plurality of HDDs can form a logical disk in a striping mode (RAID-0 mode) providing high-speed data access or can form a logical disk for a mirroring mode (RAID-1 mode) providing improved reliability.
However, when two HDDs comprise multiple logical disks operating in a RAID-0 mode and a RAID-1 mode, for example, the two HDDs are accessed in parallel in both modes. Therefore, it is not possible to access the two HDDs via both of the modes at the same time. On the other hand, the OS recognizes the HDDs as separate logical disks for RAID-0 mode and RAID-1 mode, resulting in conflicting access requests. However, since there has been no technique for performing arbitration to resolve such access conflicts, it may happen that conflicting access requests are rejected and that an access request in the RAID-0 mode for high-speed access is given a low priority.
The present invention relates to an image forming apparatus having a Redundant Array of Inexpensive/Independent Disks (RAID) control unit capable of appropriately arbitrating conflicting access requests to a physical disk, and relates to an access request arbitration method for a RAID control unit.
According to an embodiment of the present invention, an image forming apparatus having a RAID control unit comprises an access request queue and an access request arbitrating unit configured to store access requests to a logical disk sent from an operating system (OS) on the basis of fetch order determination information and to fetch the access requests.
According to an embodiment of the present invention, the image forming apparatus having the RAID control unit may further comprise an access information converting unit configured to receive the fetched access requests from the access request queue, convert logical disk access information corresponding to the access request into physical disk access information by referring to address conversion information, and send a request for transferring of access information that contains the physical disk access information.
According to an embodiment of the present invention, the image forming apparatus having the RAID control unit may further comprise a transferring unit configured to transfer the access information to a RAID controller in response to the transfer request sent by the access information converting unit.
According to an embodiment of the present invention, an access arbitration method for a RAID driver comprises a step of storing access requests in an access request queue on the basis of fetch order determination information, a step of converting logical disk access information contained in access information corresponding to the access requests into physical disk access information, and a step of supplying the access information containing the physical disk access information to a RAID controller.
Additional features and advantages are described herein, and will be apparent from the following detailed description and figures.
In the accompanying drawing:
<A First Embodiment>
An image forming apparatus 10 includes a micro processing unit (MPU) 11, an electrically erasable programmable read-only memory (EEPROM) 13, a dynamic random access memory (DRAM) 14, a Redundant Array of Inexpensive/Independent (RAID) controller 23, a network interface card (NIC) 16, a printing unit 17, and an operation panel 18 that are all connected via an interface 12. For simplicity, in
The EEPROM 13 may be a flash memory, for example. The EEPROM 13 stores a plurality of applications operating in an upper layer of an operating system (OS), such as the Linux (R) OS, employing a virtual storage system. The EEPROM 13 also stores various drivers including a RAID driver operating in a lower layer of the OS.
The DRAM 14 serves as a main memory.
The printing unit 17 may include a print engine, a sheet feeder, a sheet conveyor, and a sheet ejector. The printing unit 17 forms an electrostatic latent image on a photosensitive drum of the print engine on the basis of bitmap data and develops the electrostatic latent image using a toner. The printing unit 17 then transfers and fixes the toner image onto a sheet and ejects the sheet.
The HDD 19 and the HDD 20 include logical disks LD1, LD2, LD3, and LD4. The logical disks LD1 and LD2 are created in corresponding areas of the HDD 19 and the HDD 20 and the OS 22 may attempt accesses to both the HDD 19 and 20 at the same time in the RAID-0 mode and RAID-1 mode, respectively. The logical disks LD3 and LD4 are both accessed in a normal mode (single mode) and created in the HDD 20 and the HDD 19, respectively.
The RAID driver 21 serves as an interface between an OS 22 and the RAID controller 23.
The OS 22 includes a kernel 220 and a file system 221. When a process 24 is to access a file, the process 24 performs a file open system call to the kernel 220 such that a file path and an access mode such as read and write are specified. In response to the system call, the kernel 220 reserves a stream buffer area 222 in a kernel memory area and sends an identifier of the stream buffer area 222 to the process 24. The process 24 thereafter can access the stream buffer area 222 through the kernel 220 by specifying the identifier and the number of bytes, thereby indirectly accessing the file.
The kernel 220 obtains a head logical block address (LBA) of the file specified by the file path by referring to the file system 221. The kernel 220 sends the RAID driver 21 a file access request by specifying access information comprising a logical disk name included in the path, the LBA, the number of necessary blocks, and the head address for access in the stream buffer area 222. The size of one block may be equal to one sector (512 bytes, for example). The RAID driver 21 copies the above access information to a control block (CB) as illustrated in
In response to the request from the process 24, the OS 22 sends the RAID driver 21 a request for access to the logical disks LD1 to LD4 without considering the physical configuration of the logical disks LD1 to LD4.
However, only one of the logical disks LD1-LD4 can be accessed at the same time. Thus, a conflict between multiple access requests sent from the OS 22 to the RAID driver 21 may occur.
The RAID driver 21 performs arbitration between the conflicting access requests via an access order determining unit 210 in a manner described below.
A logical/physical disk access information converting unit 211 of the RAID driver 21 receives an arbitrated access request from the access order determining unit 210. The logical/physical disk access information converting unit 211 refers to address conversion information 212 to convert logical disk information contained in the access information corresponding to the access request into physical disk information. Specifically, the logical/physical disk access information converting unit 211 converts a logical disk name and an LBA into a physical disk name and a physical block address (PBA), respectively (illustrated in
The logical/physical disk access information converting unit 211 sends a transferring unit 214 a data transfer request by specifying the pointer *CB (the head address of the CB). In response to the data transfer request, the transferring unit 214 transfers to the RAID controller 23 the physical disk name, PBA, mode, the number of blocks, and/or the *CB for access in the stream buffer area 222 that are contained in the CB.
In response to the transfer, the RAID controller 23 executes the mode corresponding to the physical disk access information and sends an access request to the HDD 19 and/or the HDD 20. The RAID controller 23 is provided with a DMA (direct memory access) controller 230. When the access request is a read request, using the DMA controller 230, the RAID controller 23 transfers data read from the HDD 19 and/or the HDD 20 to the stream buffer area 222, by [(number of blocks)×512 bytes] beginning from the corresponding *CB address for access to the stream buffer area 222. When the access request is a write request, using the DMA controller 230, the RAID controller 23 similarly transfers data from the stream buffer area 222 to the HDD 19 and/or the HDD 20. Each of the HDD 19 and the HDD 20 includes a hard disk controller and a buffer memory, so that data communication between the RAID controller 23 and the buffer memory can be performed via the hard disk controller.
The access order determining unit 210 includes first-level queues 30-33 (example for pre-access request queues) for temporary storage, corresponding to the logical disks LD1-LD4, respectively. And the access order determining unit 210 includes a second-level queue (example for access request queue) 34, priority information 35 indicating a priority of each logical disk LD1-LD4, and an access request arbitrating unit 36 for performing arbitration control. The access request arbitrating unit 36 determines which one of the access requests (*CBs, i.e., Adr1,2,3,4,5,9 in
Operations of the access request arbitrating unit 36 will be described below.
In
The access request arbitrating unit 36 selects and fetches one access request that has the greatest fetch order determination value [(GO), where GO=(the number of access requests N)/(priority level P)] from the queues 30-33. The access request arbitrating unit 36 inputs the fetched access request to the queue 34.
In the state illustrated in
In the state illustrated in
In the state illustrated in
In the state illustrated in
In the state illustrated in
When the state illustrated in
As illustrated in
The write pointer 302 is decremented when a new *CB is stored in the element of the one-dimensional array 300 correspondingly. The read pointer 301 is decremented when the content of an element of the one-dimensional array 300 is read out. When the element in the one-dimensional array 300 designated by the read pointer 301 or the write pointer 302 indicates a head element, an address of a last element of the one-dimensional array 300 is written to the read pointer 301 or the write pointer 302, instead of decrementing the pointers. The number of access requests stored in the queue 30 is determined on the basis of the values of the read pointer 301 and the write pointer 302.
The number of access requests stored in the queues 31-34 is determined similarly to the queue 30.
For example, at Step S1, when the access request is a request for access to the logical disk LD1, the *CB of a corresponding CB is input to the queue 30. When the access request is a request for access to the logical disk LD2, the *CB of a corresponding CB is input to the queue 31. When the access request is a request for access to the logical disk LD 3, the *CB of a corresponding CB is input to the queue 32. When the access request is a request for access to the logical disk LD 4, the *CB of a corresponding CB is input to the queue 33.
The process illustrated in
At Step S10, it is determined whether or not the queue 34 is empty. If the queue 34 is not empty, the process proceeds to Step S11. If the queue 34 is empty, the procedure proceeds to Step S14.
At Step S11, one access request is fetched from the queue 34.
At Step S12, logical disk access information corresponding to the access request is converted into physical disk access information, and the converted access information is written to the corresponding CB.
At Step S13, if the RAID controller 23 is in the ready state, the CB is transferred to the RAID controller 23 by the transferring unit 214, and the process illustrated in
At Step S14, the process of access request transferring from the queues 30-33 to the queue 34 is performed, and then the process proceeds to Step S11.
At Step S20, an initial value 0 is assigned to a variable that indicates the number of access requests stored in the queue 34.
At Step S21, it is determined whether the queues 30-33 are empty. If one of the queues 30-33 is not empty, the procedure proceeds to Step S22. If all of the queues 30-33 are empty, the process is terminated.
At Step S22, the GOs of the queues 30-33 are calculated. At Step S23, one access request that has the largest GO is fetched from the queues 30-33, and the fetched access request is input to the queue 34.
At Step S24, the variable i is incremented by 1. At Step S25, it is determined whether [I≦imax] is satisfied. If [I≦imax] is satisfied, the process returns to Step S21. If [I≦imax] is not satisfied, the process is terminated. For example, imax may be 6.
By the process of
When a plurality of access requests are stored in any of the queues 30-33 at the timing that the queue 34 becomes empty (that is, the process of Step S10 proceeds to Step S14), the GO is determined not only based on the priority levels of the queues 30-33, but also on the number of the access requests of the queues 30-33. The HDD 19 and the HDD 20 can be accessed on the basis of the result of appropriately rearranging the order of the access requests.
Accordingly, for example, a delay of processing an access request can be prevented in the striping mode (RAID-0 mode) for high-speed processes. And expected operations of the striping mode are still performed. In addition, access delay can also be prevented in the mirroring mode (RAID-1 mode) for reliability even when access conflicts occur, by increasing the priority level of a disk corresponding to the RAID-1 mode.
It should be noted that the process of Step S14 based on the above rule is not limited to the case illustrated in
<A Second Embodiment>
At Step S30, the GOs of the queue 30-33 are calculated, similarly to the processing of Step S22.
At Step 531, the number of access requests to be fetched from the queues 30-33 is determined on the basis of a ratio among the GOs (4/1:4/3:4/3=3:1:1:1, in the case of
Accordingly, the state of the queues illustrated in
It should be noted that other configurations and steps in this embodiment are the same as those in the first embodiment.
The present invention includes various other embodiments. For example, other designs can be used in which the above-described configuration and steps are each performed.
For example, the priority information 35 can be manually set by a user. The setting of the priority information 35 can also be changed dynamically using an executed process.
Further, the RAID controller 23 may be configured in software.
Moreover, the calculating formula of the GO is not limited in the above embodiments. Any calculating formula can be applied, as long as it includes the priority level and the number of access requests, and it is constructed such that at least one or all of access requests are stored in the access request queue, in such a manner that the higher the priority level of a logical disk corresponding to an access request and the greater the number of access requests to the logical disk corresponding to the access request, the greater the priority given to the access request is.
Furthermore, the criterion for determining whether the process of Step S10 proceeds to Step S14 in
Number | Date | Country | Kind |
---|---|---|---|
2008-328953 | Dec 2008 | JP | national |
Number | Name | Date | Kind |
---|---|---|---|
7490185 | Morishima et al. | Feb 2009 | B2 |
20020188802 | Yagisawa et al. | Dec 2002 | A1 |
20030028727 | Kochiya | Feb 2003 | A1 |
20050102480 | Yagisawa et al. | May 2005 | A1 |
Number | Date | Country |
---|---|---|
06-259198 | Sep 1994 | JP |
2000-242441 | Sep 2000 | JP |
2001-222382 | Aug 2001 | JP |
Number | Date | Country | |
---|---|---|---|
20100169573 A1 | Jul 2010 | US |