Storage device and method for restarting the storage device

Abstract

To provide a storage device capable of continuing processing IO requests from a host device even when one of the multiple controllers stops due to a restart process associated with an operating system update, while duplicating data received from the host device.SOLUTION: A storage control program is configured to execute the reboot process to restart the updated operating system without initializing a first given area on hardware used by the operating system, and after the reboot process is complete, to reallocate virtual addresses for the first given area, and resume I / O processing by a first processor.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to a storage device and a method for restarting the storage device. For example, it is suitable for application to a storage device related to a technology in which a processor performs input / output processing of data in response to an input / output request from a host device while controlling a host interface.

Background Art

[0002] In a storage device, a plurality of storage controllers (hereinafter simply referred to as controllers) that control the storage device are provided. Even if a failure occurs in one of the controllers and the operation stops, the remaining controllers can continue the operation to ensure reliability. A typical number of such controllers is 2.

[0003] In a storage device, an OS (OPERATING SYSTEM) controlled by a processor may be installed in the controller (see Patent Document 1). In addition to the above-described failure, the function of the processor of one of the controllers may be temporarily stopped by executing a restart process of the OS (for example, a restart process associated with an update process of the OS) at an arbitrary timing.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In the event of an OS restart process at any time (in the case of the storage device described above, a restart process associated with an OS update process on one of the controllers), it is conceivable that input / output requests from the host device could be automatically reconnected to another controller with a processor that is not stopped during the restart process. However, because the processing of input / output requests is interrupted on the controller that is subject to the OS restart process at any time (in the case of the storage device described above, the controller whose OS is being updated), the host device needs to resend the input / output requests to the other controller that is not subject to the OS restart process (in the case of the storage device described above, the other controller whose OS is not being updated). In other words, in the case of the storage device, there was a risk that it would be temporarily difficult to continue input / output processing during an OS restart process at any time (in the case of the storage device described above, a restart process associated with an OS update process). Furthermore, while one controller is performing an OS restart process at any time (in the case of the storage device described above, a restart process associated with an OS update process), the data received from the host device is not duplicated, which creates a problem with data redundancy.

[0006] The present invention has been made in consideration of the above points, and aims to propose a storage device and a method for restarting the storage device that can continue to process input / output requests from a host device even when one of the controllers among the multiple controllers stops due to the operating system restart process (for example, a restart process associated with the operating system update process), and that can reliably duplicate the data received from the host device. [Means for solving the problem]

[0007] To solve the above problems, the present invention provides a storage device comprising: a first controller including a first processor that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a first memory having a storage area used by the first processor; at least one second controller including a second processor that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a second memory having a storage area used by the second processor; and an inter-controller link connecting the first controller and the second controller, wherein the first processor executes an operating system and a storage control program that controls data input / output processing in response to requests from the host device. The storage control program includes: an arrangement unit that assigns a virtual address to a first predetermined area in the first memory to which the operating system does not assign a virtual address, and places a first control queue in the first predetermined area to which data for input / output processing via the host interface is temporarily stored; a handover unit that, during a restart process to restart the operating system, takes over the input / output processing from the first processor to the second processor and releases the assignment of a virtual address to the first predetermined area; a restart unit that performs a restart process to restart the operating system without initializing the first predetermined area on the hardware used by the operating system; and a processing restart unit that, after the restart process is completed, reassigns a virtual address to the first predetermined area and resumes input / output processing by the first processor.

[0008] Furthermore, the present invention provides a method for restarting a storage device comprising: a first controller including a first processor that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a first memory having a storage area used by the first processor; at least one second controller including a second processor that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a second memory having a storage area used by the second processor; and an inter-controller link connecting the first controller and the second controller, wherein the first processor executes an operating system and a storage control program that controls data input / output processing in response to requests from the host device, and the storage control program The system is configured to perform the following steps: an arrangement step of assigning a virtual address to a first predetermined area in the first memory to which the operating system does not assign a virtual address, and placing a first control queue in the first predetermined area to which data for input / output processing via the host interface is temporarily stored; a handover step of transferring the input / output processing from the first processor to the second processor and releasing the assignment of a virtual address to the first predetermined area during a restart process to restart the operating system; a restart step of performing a restart process to restart the operating system without initializing the first predetermined area (OS-unmanaged area 204) on the hardware used by the operating system; and a processing restart step of reassigning a virtual address to the first predetermined area and resuming input / output processing by the first processor after the restart process has finished. [Effects of the Invention]

[0009] According to the present invention, even if one of the multiple controllers stops due to an operating system restart process (for example, a restart process associated with an operating system update process), it is possible to continue processing I / O requests from the host device and to duplicate the data received from the host device. [Brief explanation of the drawing]

[0010] [Figure 1] This is a system configuration diagram showing an example of the configuration of a storage device according to the first embodiment. [Figure 2] This figure shows an example of a memory space. [Figure 3] This flowchart shows an example of the procedure for updating and restarting the operating system. [Figure 4] This diagram illustrates an example of the composition of OQ and IQ. [Figure 5] This diagram illustrates the data transfer path related to host I / O processing before host I / O handover. [Figure 6] This diagram illustrates the data transfer sequence related to host I / O processing before host I / O handover. [Figure 7] This diagram illustrates an example of a P2P data transfer path. [Figure 8] This is a flowchart illustrating an example of the host I / O handover procedure. [Figure 9] This diagram illustrates the data transfer path related to host I / O processing after host I / O handover. [Figure 10] This diagram illustrates the data transfer sequence related to host I / O processing after host I / O handover. [Figure 11] This flowchart shows an example of the procedure for restarting host I / O. [Figure 12] This diagram illustrates the data transfer path related to host I / O processing after host I / O handover in the storage device according to the second embodiment. [Figure 13] This diagram illustrates the data transfer sequence related to host I / O processing after host I / O handover. [Figure 14] It is a flowchart showing an example of the host I / O transfer process procedure. [Figure 15] It is a flowchart showing an example of the host I / O restart process procedure. [Figure 16] It is a diagram for explaining a data transfer path related to host I / O processing before host I / O transfer in the storage device according to the third embodiment. [Figure 17] It is a diagram for explaining a data transfer path related to host I / O processing after host I / O transfer.

Mode for Carrying Out the Invention

[0011] Hereinafter, an embodiment of the present invention will be described in detail based on the drawings. Throughout all the embodiments, it is assumed that the components with the same reference numerals are substantially the same. In addition, since the processing executed by the processor is performed while appropriately using a storage resource (for example, a memory) and a communication interface device (for example, a communication port), the subject of the processing may be the processor. The processor may have dedicated hardware in addition to the CPU (Central Processing Unit).

[0012] In addition, in the following description, "memory" is a main storage device in a general computer system and may be one or more storage devices. For example, the memory may be at least a main storage device among a main storage device (typically a volatile storage device) and an auxiliary storage device (typically a non-volatile storage device).

[0013] In addition, in the following description, "PDEV" means a physical storage device and may typically be a non-volatile storage device (for example, an auxiliary storage device). The PDEV may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

[0014] (1) First Embodiment A storage device according to the first embodiment will be described with reference to Figures 1 to 11. Figure 1 is a system configuration diagram showing an example of the configuration of the storage device 100 according to the first embodiment. In the illustrated configuration example, some of the connection relationships between each element are omitted for the sake of simplicity (the same applies to drawings other than Figure 1 below).

[0015] The storage device 100 according to this embodiment includes a first controller (hereinafter also referred to as "controller") 121 which includes a CPU 123 as an example of a first processor that controls data input / output processing in response to requests from a host device via a host interface that controls the communication protocol with the host device, and a first memory (hereinafter also referred to as "memory") 124 having a storage area used by the CPU 123; at least one second controller (hereinafter also referred to as "controller") 101 which includes a CPU 103 as an example of a second processor that controls data input / output processing in response to requests from a host device via a host interface that controls the communication protocol with the host device, and a second memory (hereinafter also referred to as "memory") 104 having a storage area used by the CPU 103; and an inter-controller link 111 connecting controller 121 and controller 101. Since both controllers 121 and 101 have substantially the same configuration and function, only one of the control sides may be referred to unless it is necessary to specifically refer to both. Note that the number of controllers in the storage device 100 is not limited to two, and may be more. Furthermore, this embodiment will describe the process of restarting the OS of the controller of the storage device 100 at any time, using the example of restarting the OS in conjunction with an OS update process for the controller. However, it is not limited to this; for example, the OS of the controller of the storage device 100 may be restarted when the administrator of the storage device 100 deems it necessary. A more detailed explanation follows below.

[0016] The storage device 100 includes controllers 101 and 121, and a PDEV BOX 140 having multiple PDEVs, including PDEVs 142 and 162.

[0017] The storage device 100 is configured with logical volumes capable of storing data on multiple drive devices, and data input / output processing is performed by controllers 101 and 121.

[0018] The controller 101 includes a host interface 102, a CPU 103, memory 104, and an NTB 108. The host interface 102, CPU 103, and NTB 108 are, for example, PCIe (Peripheral Component Intercon n They are interconnected by PCIe links. Similarly, controller 121 has host IF 122, CPU 123, memory 124, and NTB 128. Host IF 122, CPU 123, and NTB 128 are interconnected by PCIe links, for example. CPU 103 and memory 104, and CPU 123 and memory 124 are connected by memory buses, respectively.

[0019] Furthermore, controllers 101 and 121 are equipped with management terminal interfaces 171 and 172, respectively, for connecting to the management terminal 174 via the management terminal network 173. The administrator of the storage device 100 can operate the management terminal 174 to perform operations such as changing the settings of the storage device 100, updating the controller OS (hereinafter also abbreviated as "OS"), and restarting the device.

[0020] CPU 103 contains multiple cores 105 and the remaining uncore 106. The uncore 106 contains DMA (Direct Memory Access) 107. Similarly, CPU 123 contains multiple cores 125 and the remaining uncore 126. The uncore 126 contains DMA 127.

[0021] The host devices 150 and 600, which access the storage device 100, are connected to the storage device 100 via host IFs 102 and 122, respectively. The host devices 150 and 600 are connected to the host IFs 102 and 122 by transmission lines such as Fibre Channel cables or Ethernet cables. Alternatively, the host devices 150 and 600 and the host IFs 102 and 122 may be connected via a storage area network (not shown) consisting of multiple transmission lines and multiple switches.

[0022] Host IFs 102 and 122 convert the data transfer protocol between the host devices 150 and 600 and the storage device 100, and the data transfer protocol within the controllers 101 and 121.

[0023] The PDEV BOX 140 is connected to controllers 101 and 121 via links 131, 132, 151, and 152. The PDEV BOX 140 includes PDEV switches 141 and 161 that connect PDEVs 142 and 162 via links 143, 144, 163, and 164. In this embodiment, links 131, 132, 143, 144, 151, 152, 163, and 164 are PCIe links. PDEV switches 141 and 161 are PCIe switches, and PDEVs 142 and 162 are dual-port NVMe drives. Figure 1 illustrates an example of the PDEV BOX 140 with only two PDEVs installed, but the number of PDEVs installed in the PDEV BOX 140 is arbitrary. CPUs 103 and 123 control data transfer between host devices 150 and 600 connected via host IFs 102 and 122, and PDEVs 142 and 162 connected via PDEV switches 141 and 161. Furthermore, CPUs 103 and 123 control data transfer between controllers.

[0024] Memory devices 104 and 124 are the main memory devices for CPUs 103 and 123, respectively, and store programs executed by CPUs 103 and 123 (OS, storage control programs, etc.) and management tables that CPUs 103 and 123 refer to. Memory devices 104 and 124 are also used as cache memory for controllers 101 and 121, respectively.

[0025] NTB108 and NTB128 are connected by an inter-controller link 111, which is a PCIe link. CPU 103 and CPU 123 can communicate with each other via the inter-controller link 111. In this way, the storage device 100 is configured as a dual controller with the two controllers 101 and 121. CPUs 103 and 123 transfer data received from the host, which is duplicated between the two controllers, and metadata used for controller control over the inter-controller link 111.

[0026] Memory 104 and 124 have OQ (Outbound Queue) and IQ (Inbound Queue), which are queues for controlling message transfer between CPU 103 and 123 and host IF 102 and 122. OQ is a queue that controls message transfer from host IF to CPU, and IQ is a queue that controls message transfer from CPU to host IF. Memory 104 has OQ109 and IQ110, which are queues for controlling message transfer between CPU 103 and host IF 102. Memory 124 also has OQ129 and IQ130, which are queues for controlling message transfer between CPU 123 and host IF 122.

[0027] In Figure 1, OQ109 is also referred to as "OQ01", IQ110 as "IQ01", OQ129 as "OQ11", and IQ130 as "IQ11".

[0028] The process by which host IFs 102 and 122 store data received from host devices 150 and 600 in memories 104 and 124, or the process by which host IFs 102 and 122 send data stored in memories 104 and 124 to host devices 150 and 600, and related processes, will be referred to as host I / O processing (hereinafter also referred to as "input / output processing").

[0029] Furthermore, the process of writing data stored in memory 104 and 124 to PDEV 142 and 162, or the process of reading data stored in PDEV 142 and 162 to memory 104 and 124, and related processes will be referred to as backend processing.

[0030] Furthermore, the process of duplicating data received from host devices 150 and 600 between memory 104 and memory 124 using DMA 107 and 127, and related processes, will be referred to as host data duplication processing.

[0031] Figure 2 shows an example of the memory space used by CPU 123. The physical address space 201 includes the OS-recognized area 202, which is a memory address area that the OS can recognize. The memory space used by CPU 103 has a similar configuration, so its explanation is omitted.

[0032] The OS-recognized area 202 includes the OS-managed area 203, the OS-unmanaged area 204 as an example of a first predetermined area, and the I / O area 205. The OS-managed area 203 is a memory area to which the OS allocates virtual addresses and uses. The OS-unmanaged area 204 is a memory area to which the OS does not allocate virtual addresses and which is not used by the OS itself. The I / O area 205 is a memory area to which I / O devices can be accessed by reading and writing to memory.

[0033] CPU 123 executes the OS and a storage control program that controls data input / output processing in response to requests from the host device. The OS management area 203 includes the OS usable area 206. The OS usable area 206 is where the OS and processes of the storage control program are located.

[0034] The OS-unmanaged area 204 includes a storage control program information storage area 207. The storage control program information storage area 207 contains the cache memory of the storage device 100, storage control program management information, host interface control queues, host interface management information, buffer areas, work areas, etc. The storage control program assigns virtual addresses to a predetermined area, which is at least a portion of the storage area of ​​the OS-unmanaged area 204, and uses that predetermined area as the storage control program information storage area 207. The OS-unmanaged area 204 is not typically used by the OS, for example, by assigning virtual addresses to it.

[0035] The storage control program information storage area 207 is used, for example, as a storage cache memory, buffer area, or work area, and includes management information for the storage control program, host interface control queues, and management information. In this context, the host interface control queues correspond to OQ129 and IQ130 as examples of first control queues if CPU 123 is an example of a first processor, and to OQ109 and IQ110 as examples of second control queues if CPU 103 is an example.

[0036] The I / O area 205 contains access areas for I / O devices, including the host IF 102, and the access area for the NTB 108. The CPU 123 can access the memory 104 of the other controller 101 and the host IF 102 via the access area of ​​the NTB 108.

[0037] The storage control program assigns a virtual address to an OS-unmanaged area 204, which is an example of a first predetermined area in memory 124 (first memory) to which the operating system does not assign a virtual address, and places OQ109 and IQ110, which are examples of a first control queue where data for input / output processing via the host interface is temporarily stored, within the OS-unmanaged area 204 (placement section).

[0038] The storage control program performs the following operations during the restart process, which involves restarting the operating system. Here, this restart process is, for example, the process of restarting the updated operating system following an operating system update. First, the storage control program takes over the input / output processing from CPU 123 (first processor) to CPU 103 (second processor) and releases the allocation of virtual addresses to the OS-unmanaged area 204 (handover unit).

[0039] The storage control program performs a restart process (restart section) that restarts the updated operating system without initializing the OS-unmanaged area 204 on the hardware used by the operating system. Next, after the restart process described above is completed, the storage control program reassigns a virtual address to the OS-unmanaged area 204 and resumes input / output processing by the first processor (e.g., CPU 123) (processing restart section).

[0040] CPU 103 is an example of a second processor and accesses the host interface via a data transfer path through the inter-controller link 111. This data transfer path includes a data transfer path between two ports provided by CPU 123 (the first processor). CPU 103 accesses OQ 109 and IQ 110, which are examples of the first control queues, via the data transfer path through the inter-controller link 111.

[0041] CPU123 is equipped with DMA127, and CPU103 is equipped with DMA1 0It is equipped with 7. Before the input / output processing is handed over from CPU 123 to CPU 103, the data received from the host device is duplicated by the data transfer from memory 124 (first memory) to memory 104 (second memory) by DMA127 of CPU 123, and after the input / output processing is handed over from CPU 123 to CPU 103, DMA1 of CPU 103 0 Data transfer from memory 124 (the first memory) to memory 104 by step 7 duplicates the data received from the host device.

[0042] The storage control program, during the operating system restart process, stops the CPU 123 from writing data received from the host device, which is stored in memory 124 (the first memory), to the storage medium.

[0043] Figure 3 is a flowchart showing an example of the procedure for updating the controller's OS and the associated restart process in the storage device 100. This flowchart is executed by the OS update processing program 300 under the control of the controller's CPU 123, which has received an instruction from the management terminal 174 to update the controller 121's OS. In this embodiment, as an example, the case of updating the OS running on the CPU 123 of the controller 121 is described.

[0044] First, the administrator of the storage device 100 instructs the controller 121 to update the OS via the management terminal 174. Upon receiving the instruction, the CPU 123 of the controller 121 executes the OS update processing program 300.

[0045] The OS update processing program 300 takes over the host I / O processing that was being performed on the controller 121 to the controller 101 (step S301). Details of this host I / O handover process will be described later. This process allows the storage device 100 to continue host I / O processing even during restart processing associated with OS update processing, thus maintaining availability. Furthermore, because host I / O processing is continued during OS restart processing, there is no need to resend I / O requests from the host device during OS restart processing, thus reducing the power consumption required for resending I / O requests.

[0046] Next, the OS update processing program 300 stops the storage control program that was running on the CPU 123 of the controller 121 (step S302). Note that the OS update processing program 300 may be included in the storage control program. In that case, in step S302, the parts of the storage control program other than the OS update processing program 300 are stopped. For example, the storage control program and the OS update processing program 300 are run as separate processes, and the storage control program process is stopped.

[0047] Next, the OS update processing program 300 makes the storage control program information storage area (207 in Figure 2) in the memory 124, which has the memory area used by the CPU 123, inaccessible by virtual address (step S303). In other words, the allocation of virtual addresses to the storage control program information storage area 207 is released by the execution of the OS's munmap instruction or the like.

[0048] Next, the OS update processing program 300 executes the OS update process and restart process on the CPU 123 of the controller 121 (step S304). Here, in the OS restart process, a mechanism is adopted that does not involve hardware initialization, for example, a mechanism that enables live booting of a new kernel on the currently running kernel. As such a mechanism, if the OS is Linux (registered trademark), kexec can be adopted. As a result, even if the OS is restarted, the CPU, memory and host interface are not initialized, so data stored in the OS-unmanaged area of ​​memory is retained and the operation of the host interface can continue.

[0049] After the OS restarts, the OS update processing program 300 makes the storage control program information storage area 207 accessible again by virtual address on the CPU 123 of the controller 121 (step S305). In other words, virtual addresses are assigned to the storage control program information storage area 207 by executing an OS mmap instruction or the like.

[0050] Next, the OS update processing program 300 restarts the storage control program using data such as storage control program management information that was stored in the storage control program information storage area 207 (step S306).

[0051] Next, the OS update processing program 300 resumes the host I / O processing, which was handed over to the controller 101 in step S301, on the controller 121 (step S307). Details of this host I / O resumption process will be described later.

[0052] As a result, the controller 121 can quickly resume the operation of the storage control program while continuing host I / O processing, compared to performing an OS restart process that involves initializing hardware that cannot continue host I / O processing.

[0053] Figure 4 illustrates an example of the configuration of OQ and IQ in storage device 100. While OQ129 and IQ130 are described as an example, the same applies to other OQ and IQ configurations such as OQ109 and IQ110.

[0054] Both OQ129 and IQ130 store entries in a total of N elements, numbered from 0 to N-1. In OQ129, the content of an entry is, for example, a host I / O command received from the host device. In IQ130, the content of an entry is, for example, a response corresponding to a completed host I / O command, or a data transfer list instructed by the CPU to the host interface. Each entry also contains exchange identification information (i.e., an exchange ID) indicating which host I / O exchange the entry is related to. An exchange refers to a series of operations related to read and write operations between the host and storage.

[0055] In Figure 4, OQ129 shows, for example, entries stored in elements i-1 to i+4. The other elements of OQ129 are empty. OQPI (Producer Index) 401 indicates the location of the element where the host interface will next store an entry. OQCI (Consumer Index) 402 indicates the location of the element where the next entry to be read by the CPU is stored. If OQPI 401 and OQCI 402 point to the same element, it indicates that OQ129 is empty and contains no unprocessed entries. Additionally, the i-1th element stores the most recently processed entry. The CPU can determine which exchange the entry associated with has been processed by examining the exchange ID of this entry.

[0056] In Figure 4, IQ130 shows, for example, entries stored in elements j-1 through i+3. The other elements of IQ130 are empty. IQPI411 indicates the location of the element where the CPU will store the next entry. IQCI412 indicates the location of the element where the next entry to be read by the host interface is stored. If IQPI411 and IQCI412 point to the same element, it indicates that IQ130 is empty and contains no unprocessed entries. Additionally, the j-1th element contains the most recently processed entry. The CPU can determine which exchange the entry associated with has been processed by examining the exchange ID of this entry.

[0057] The queue indices OQPI, OQCI, IQPI, and IQCI are stored, as needed, at predetermined addresses in memory, in host interface registers, or both.

[0058] Figure 5 illustrates the data transfer path related to host I / O processing before host I / O handover in the storage device 100. Note that in the illustrated example, the management terminal 174 and other components shown in Figure 1 are omitted (the same applies in the following explanation). As an example, the data transfer path when the CPU 123 core 500 controls the host IF 122 in the controller 121 will be explained.

[0059] The host IF122, which receives host I / O from the host device 600, accesses OQ129, IQ130 and their queue indices, OQPI and IQCI, located in memory 124 via the data transfer path 501 through the CPU 123.

[0060] Furthermore, the host IF122 either stores the data received from the host device 600 in the memory 124 via the data transfer path 501, or transmits the data stored in the memory 124 to the host device 600.

[0061] Core 500 accesses OQ129, its queue index OQPI, and IQ130 in memory 124 via data transfer path 502.

[0062] Furthermore, Core 500 accesses the queue index OQCI of OQ129 and the queue index IQPI of IQ130 located on Host IF122 via the data transfer path 503. Core 500 also uses DMA 127 to transfer data received from Host device 600 and stored in memory 124 from memory 124 to controller 101's memory 104 via the data transfer path 504, which passes through CPU 123, inter-controller link 111, and CPU 103. This allows the data received from Host device 600 to be duplicated in memory 104 of controller 101 and memory 124 of controller 121 (the host data duplication process described above).

[0063] Figure 6 illustrates the data transfer sequence related to host I / O processing before host I / O handover.

[0064] Here, as an example, we describe the case where host IF122 and CPU123's core 500 use OQ129 and IQ130 located in memory 124. Note that in Figure 6, OQ129 is displayed as "OQ11" and IQ130 as "IQ11".

[0065] First, the host device 600 sends a host I / O command 601 to the host IF122.

[0066] Upon receiving host IO command 601, host IF122 enqueues entry 602 containing the command details to OQ129 (step S603).

[0067] Next, host IF122 updates the OQPI of OQ129 in memory 124 to notify core 500 that it has enqueued entry 602 to OQ129 (step S604).

[0068] Core 500 checks for any unprocessed entries in OQ129 by polling OQPI of OQ129 (step S605). If there are unprocessed entries, Core 500 reads the entries containing the host IO command content from OQ129 (step S606). Furthermore, Core 500 updates OQCI of OQ129 located on host IF122 (step S607).

[0069] Next, core 500 enqueues an entry to IQ130 containing a data transfer list corresponding to host IO command 601 (step S608). Furthermore, core 500 updates the IQPI of IQ130, which is located on host IF122 (step S609).

[0070] The updated IQPI host IF122 reads entries containing the data transfer list from IQ130 (step S610).

[0071] Next, the host IF122 performs data transfer between the host device 600 and the memory 124 according to the data transfer list contained in the entry read from IQ130 (step S611).

[0072] Once the data transfer is complete, host IF122 updates the IQCI of IQ130 located in memory 124 (step S612).

[0073] In this way, core 500 can process host I / O command 601 received by host IF122.

[0074] Figure 7 illustrates an example of a P2P (peer-to-peer) data transfer path in CPU 123.

[0075] The uncore 126 of CPU 123 includes a PCIe root complex 701. Furthermore, root complex 701 has multiple root ports, including root ports 702 and 703. Root port 702 is connected to host IF 122, and root port 703 is connected to NTB 128. As shown in Figure 1, NTB 128 is connected to other controllers 101 via inter-controller link 111. Data transfer that takes place via path 704 through root port 702, root complex 701, and root port 703 is called P2P data transfer.

[0076] Figure 8 is a flowchart illustrating an example of a host I / O handover procedure between controllers in the storage device 100. This process flow is executed in step S301 of the OS update processing program 300 in Figure 3. Alternatively, this process flow is executed on the CPU 103 or CPU 123 of the controller that receives a host I / O handover instruction from the management terminal 174. Hereafter, this process flow will be referred to as the host I / O handover processing program 800. As an example, we will describe the case where controller 101 takes over host I / O processing from controller 121.

[0077] First, the host I / O handover processing program 800 stops the host IF122 driver running on the controller 121's CPU 123 (step S801). Stopping the host IF driver here means stopping processing on the host IF control queue. Therefore, stopping the host IF driver does not initialize the host IF, so host link down or similar issues do not occur.

[0078] Next, the host I / O handover processing program 800 executes the host IF122 driver on the controller 101's CPU 103 (step S802). Executing the host IF driver here means starting processing on the host IF control queue. Therefore, executing the host IF driver does not initialize the host IF, preventing host link down events. The host IF122 driver running on CPU 103 can take over the host I / O processing from the host IF122 driver that was running on CPU 123 by checking the queue indices OQ129 and IQ130. In other words, even if the entity operating the host IF control queue changes, the host IF can continue to operate.

[0079] Next, the host I / O handover processing program 800 stops the backend processing currently running on the CPU 123 of the controller 121 (step S803). Since the data received from the host device is duplicated in memory 104 and memory 124, even if the backend processing on CPU 123 is stopped, the storage device 100 can continue to operate as long as CPU 103 is still executing the backend processing. As a result, host I / O processing is handed over from controller 121 to controller 101.

[0080] Figure 9 illustrates the data transfer path related to host I / O processing after host I / O handover in the storage device 100. As an example, it illustrates the data transfer path when the core 900 of the CPU 103 belonging to the controller 101 controls the host IF 122 of the controller 121.

[0081] The host IF122, which receives host I / O from the host device 600, accesses OQ129, IQ130 and their queue indices, OQPI and IQCI, located in memory 124, via the data transfer path 901 through CPU 123.

[0082] Furthermore, the host IF122 either stores the data received from the host device 600 in the memory 124 via the data transfer path 901, or transmits the data stored in the memory 124 to the host device 600.

[0083] Core 900 accesses OQ129, its queue index OQPI, and IQ130 in memory 124 via a data transfer path 902 through the inter-controller link 111 and CPU 123.

[0084] Furthermore, Core 900 accesses OQCI, the queue index of OQ129 located on Host IF122, and IQPI, the queue index of IQ130, via a data transfer path 903 that passes through the inter-controller link 111 and CPU 123. The data transfer path 903 includes a P2P data transfer path in CPU 123.

[0085] Furthermore, the core 900 receives data from the host device 600 and stores it in memory 124, and uses DMA 107 to transfer it from memory 124 to the controller 101's memory 104 via a data transfer path 904 that passes through CPU 123, the inter-controller link 111, and CPU 103. This allows the data received from the host device 600 to be duplicated in the controller 101's memory 104 and the controller 121's memory 124 (the host data duplication process described above).

[0086] Figure 10 is a diagram illustrating the data transfer sequence related to host I / O processing after host I / O handover in the storage device 100.

[0087] Here, as an example, we describe the case where host IF122 and CPU103's core 900 use OQ129 and IQ130 located in memory 124. Note that in Figure 10, OQ129 is displayed as "OQ11" and IQ130 as "IQ11".

[0088] First, the host device 600 sends a host IO command 1001 to the host IF122. Upon receiving the host IO command 1001, the host IF122 enqueues an entry 1002 containing the command details to the OQ129 (step S1003).

[0089] Next, host IF122 updates the OQPI of OQ129 in memory 124 to notify core 900 that it has enqueued entry 1002 to OQ129 (step S1004).

[0090] Core 900 checks for any unprocessed entries in OQ129 by polling OQPI of OQ129 (step S1005). If there are unprocessed entries, Core 900 reads the entries containing the host IO command content from OQ129 (step S1006). Furthermore, Core 900 updates OQCI of OQ129 located on host IF122 (step S1007).

[0091] Next, core 900 enqueues an entry containing a data transfer list corresponding to host IO command 1001 to IQ130 (step S1008). Furthermore, core 900 updates the IQPI of IQ130, which is located on host IF122 (step S1009).

[0092] The host IF122, whose IQPI has been updated, reads entries containing the data transfer list from IQ130 (step S1010).

[0093] Next, the host IF122 performs data transfer between the host device 600 and the memory 124 according to the data transfer list contained in the entry read from IQ130 (step S1011).

[0094] Once the data transfer is complete, host IF122 updates the IQCI of IQ130 in memory 124 (step S1012). In this way, core 900 can process the host IO command 1001 received by host IF122.

[0095] Figure 11 is a flowchart illustrating an example of the procedure for resuming host I / O processing in a controller of storage device 100 that had handed over host I / O processing to another controller for the purpose of updating and restarting the controller OS. This processing flow is executed in step S307 of the OS update processing program 300 in Figure 3. Alternatively, this processing flow is executed on the CPU 103 or CPU 123 of the controller that received a command to resume host I / O processing from the management terminal 174. Hereafter, this processing flow will be referred to as the host I / O resume processing program 1100. As an example, we will describe the case where controller 101 has taken over host I / O processing from controller 121 and then controller 121 resumes host I / O processing.

[0096] First, the host I / O restart processing program 1100 stops the host IF122 driver running on the CPU 103 of the controller 101 (step S1101). Stopping the host IF driver here means stopping processing on the host IF control queue. Therefore, stopping the host IF driver does not initialize the host IF, so host link down and other issues do not occur.

[0097] Next, the host I / O restart processing program 1100 restarts the host IF122 driver on the CPU 123 of the controller 121 (step S1102). Restarting the host IF driver here means restarting processing on the host IF control queue. Therefore, restarting the host IF driver does not initialize the host IF, so host link down or similar issues do not occur. The host IF122 driver running on CPU 123 can take over the host I / O processing of the host IF122 driver that was running on CPU 103 by checking the queue indices of OQ129 and IQ130. In other words, even if the entity operating the host IF control queue changes, the host IF can continue to operate.

[0098] Next, the host I / O restart processing program 1100 restarts the backend processing on the CPU 123 of the controller 121 (step S1103). As a result, the host I / O processing is taken over from the controller 101 to the controller 121.

[0099] The OS update procedure in this embodiment described above can be summarized as follows. As an example, we assume a storage device 100 with a dual controller configuration where controller 121 is subject to OS update and controller 101 is not. In addition, the storage control program information storage area 207, which includes the host interface control queue and management information, is located in the area 204 outside of OS management.

[0100] First, the OS update processing program 300 of the storage device 100 transfers the host I / O processing of the controller 121 from the core 500 of the CPU 123 of the controller 121 to the core 900 of the CPU 103 of the controller 101. The CPU 103 of the controller 101 accesses the host IF 122 of the controller 121 via the inter-controller link 111 and the P2P data transfer path of the CPU 123 to control the host I / O processing.

[0101] Furthermore, the OS update processing program 300 ensures that the backend processing in controller 121 is not performed by the CPU 123 of controller 121, but by the CPU 103 of controller 101.

[0102] Next, the OS update processing program 300 makes the storage control program information storage area 207 inaccessible via a virtual address.

[0103] Then, the CPU 123 of controller 121, which no longer performs host I / O processing and backend processing, performs OS update processing and restart processing that does not involve hardware initialization, including CPU 123, host IF 122, and memory 124. During this process, the CPU 103 of controller 101 continues host I / O processing of the host IF 122 of controller 121. Furthermore, the CPU 103 of controller 101 performs host data duplication processing, which duplicates the data received from the host device 600 in the memory 104 of controller 101 and the memory 124 of controller 121.

[0104] After the OS restarts, the OS update processing program 300 makes the storage control program information storage area 207 accessible by a virtual address.

[0105] Then, the OS update processing program 300 restarts the host I / O processing of the host IF122, which had been handed over to the CPU103 core 900 of the controller 101, on the CPU123 core 500 of the controller 121.

[0106] As described above, the storage device 100 according to this embodiment can perform OS update processing and restart processing while maintaining the availability of the dual controller and data redundancy.

[0107] Furthermore, if controller 101 is to be included in the OS update and controller 121 is not, the OS update processing program 300 should control the host I / O processing of controller 101 so that it is handed over from the CPU 103 core 900 of controller 101 to the CPU 123 core 500 of controller 121.

[0108] The storage device 100 according to this embodiment includes a controller 121 (first controller) which includes a CPU 123 (first processor) that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a memory 124 (first memory) having a storage area used by the CPU 123; at least one controller 101 (second controller) which includes a CPU 103 (second processor) that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a memory 104 (second memory) having a storage area used by the CPU 103; and an inter-controller link 111 connecting controller 121 and controller 101. At least CPU 123 executes an operating system and a storage control program that controls data input / output processing in response to requests from the host device. The storage control program performs the following steps: assigning a virtual address to an OS-unmanaged area 204 (a first predetermined area) in memory 124 where the operating system does not assign virtual addresses, and placing a first control queue in the OS-unmanaged area 204 where data for input / output processing via the host interface is temporarily stored; a handover step in which, during a restart process to restart the operating system, input / output processing is handed over from CPU 123 to CPU 103 and the assignment of a virtual address to the OS-unmanaged area 204 is released; a restart step in which a restart process is performed to restart the operating system without initializing the OS-unmanaged area 204 on the hardware used by the operating system; and a restart step in which, after the restart process is completed, a virtual address is reassigned to the OS-unmanaged area 204 and input / output processing by CPU 123 is resumed.

[0109] In this way, even if one of the multiple controllers 101, 121 stops due to a restart process associated with an operating system update, the CPU 123 of one controller 121 can take over to the CPU 103 of the other controller 101, allowing for continuous processing of I / O requests from the host device. Furthermore, this method ensures reliability by duplicating the data received from the host device.

[0110] CPU 103 is an example of a second processor and accesses the host interface via a data transfer path through the inter-controller link 111. This data transfer path includes a data transfer path between two ports provided by CPU 123 (the first processor). CPU 103 accesses OQ 109 and IQ 110, which are examples of the first control queues, via the data transfer path through the inter-controller link 111.

[0111] CPU123 is equipped with DMA127, and CPU103 is equipped with DMA1 0 It is equipped with 7. Before the input / output processing is handed over from CPU 123 to CPU 103, the data received from the host device is duplicated by the data transfer from memory 124 (first memory) to memory 104 (second memory) by DMA127 of CPU 123, and after the input / output processing is handed over from CPU 123 to CPU 103, DMA1 of CPU 103 0 The data transfer from memory 124 (the first memory) to memory 104 by step 7 duplicates the data received from the host device. This allows for continuous processing of I / O requests from the host device before and after the aforementioned handover, and also improves reliability.

[0112] The storage control program, during the operating system restart process, stops the CPU 123 from writing data received from the host device, which is stored in memory 124 (the first memory), to the storage medium. This ensures reliability.

[0113] (2) Second embodiment Referring to Figures 12 to 15, a storage device according to the second embodiment will be described. The configuration of the storage device according to the second embodiment is the same as that of the storage device according to the first embodiment shown in Figures 1 to 11, except for the differences described below, so the explanation of the similarities will be omitted. In this embodiment as well, the process of restarting the OS of the storage device controller at any time will be explained using the process of restarting the OS in conjunction with the update process of the controller OS as an example, but it is not limited to this, and for example, the OS of the storage device controller may be restarted when the administrator of the storage device deems it necessary.

[0114] Figure 12 illustrates the data transfer path related to host I / O processing after host I / O handover in the storage device 1200. Here, similar to the storage device 100 in the first embodiment, it is assumed that the host I / O received by the host IF 1222 is handed over from controller 1221 to controller 1201.

[0115] Storage device 1200 has the same configuration as storage device 100, except for controllers 1201 and 1221. Controllers 1201 and 1221 have the same configuration as controllers 101 and 121, except for host interfaces 1202 and 1222.

[0116] Host IF1202 and 122 differ from Host IF102 and 122 in that each CPU core controlling them can be assigned a different set of OQ and IQ. For example, if CPU 123's core 500 controls Host IF1222, it will use OQ1229 and IQ1230 located in memory 124. In contrast, if CPU 103's core 900 controls Host IF1222, it will use OQ1209 and IQ1210 located in memory 104. Then, instructions from CPU 103 or CPU 123 to Host IF1222 determine which set of OQ and IQ to access.

[0117] As an example, we will describe the data transfer path when the core 900 of CPU 103, which belongs to controller 1201, controls the host IF 1222 of controller 1221.

[0118] The host IF1222, which receives host I / O from the host device 600, accesses OQ1209, IQ1210 and their queue indices, OQPI and IQCI, located in memory 104, via a data transfer path 1211 that passes through CPU 123, the inter-controller link 111, and CPU 103. The data transfer path 1211 includes a P2P data transfer path in CPU 123.

[0119] Furthermore, the host IF1222 either stores the data received from the host device 600 in the memory 124 via the data transfer path 1212, or transmits the data stored in the memory 124 to the host device 600.

[0120] Core 900 accesses OQ1209, its queue index OQPI, and IQ1210 in memory 104 via data transfer path 1213.

[0121] Furthermore, Core 900 accesses OQCI, the queue index of OQ1209 located on Host IF1222, and IQPI, the queue index of IQ1210, via a data transfer path 1214 that passes through the inter-controller link 111 and CPU 123. The data transfer path 1214 includes a P2P data transfer path in CPU 123.

[0122] Furthermore, the core 900 receives data from the host device 600 and stores it in memory 124, and uses DMA 107 to transfer it from memory 124 to the controller 101's memory 104 via a data transfer path 1215 that passes through CPU 123, inter-controller link 111, and CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of controller 1201 and the memory 124 of controller 1221 (the host data duplication process described above).

[0123] The data transfer path when the core 500 of the CPU 123 belonging to the controller 1221 controls the host IF 1222 of the controller 1221 is the same as in Figure 5, so the explanation is omitted.

[0124] Figure 13 illustrates the data transfer sequence related to host I / O processing after host I / O handover in the storage device 1200.

[0125] Here, as an example, we describe the case where the host IF1222 and CPU 103's core 900 use OQ1209 and IQ1210 located in memory 104. Note that in Figure 13, OQ1209 is displayed as "OQ02" and IQ1210 as "IQ02".

[0126] First, host device 600 sends host IO command 1301 to host IF1222. Upon receiving host IO command 1301, host IF1222 enqueues entry 1302 containing the command details to OQ1209 (step S1303).

[0127] Next, host IF1222 updates the OQPI of OQ1209 in memory 104 to notify core 900 that it has enqueued entry 1302 to OQ1209 (step S1304).

[0128] Core 900 checks for any unprocessed entries in OQ1209 by polling OQPI of OQ1209 (step S1305). If there are unprocessed entries, Core 900 reads the entries containing the host IO command content from OQ1209 (step S1306). Furthermore, Core 900 updates OQCI of OQ1209 located on host IF1222 (step S1307).

[0129] Next, core 900 enqueues an entry containing a data transfer list corresponding to host IO command 1301 to IQ1210 (step S1308). Furthermore, core 900 updates the IQPI of IQ1210, which is located on host IF1222 (step S1309).

[0130] The updated IQPI host IF1222 reads entries containing the data transfer list from IQ1210 (step S1310).

[0131] Next, the host IF1222 performs data transfer between the host device 600 and the memory 124 according to the data transfer list contained in the entry read from IQ1210 (step S1311).

[0132] Once the data transfer is complete, the host IF1222 updates the IQCI of IQ1210 in memory 104 (step S1312). In this way, core 900 of CPU 103 can process the host IO command 1301 received by the host IF1222.

[0133] Figure 14 is a flowchart illustrating an example of a host I / O handover procedure between controllers in storage device 1200. This process flow is executed in step S301 of the OS update processing program 300 in Figure 3. Alternatively, this process flow is executed on CPU 103 or CPU 123 of the controller that receives a host I / O handover instruction from the management terminal. Hereafter, this process flow will be referred to as the host I / O handover processing program 1400. As an example, we will describe the case where controller 1201 takes over host I / O processing from controller 1221.

[0134] First, the host I / O handover processing program 1400 executes the host IF1222 driver on the controller 1201's CPU 103 (step S1401). At this time, OQ1209 and IQ1210 are empty, and host I / O processing using them has not yet been performed. Executing the host IF driver here means starting processing on the host IF control queue. Therefore, executing the host IF driver does not initialize the host IF, and thus host link down or similar issues do not occur.

[0135] Next, the host IO handover processing program 1400 instructs host IF1222 to switch queues (step S1402). Before receiving the queue switching instruction, host IF1222 enqueues entries related to host IO commands received from the host device to OQ1229. After receiving the queue switching instruction, host IF1222 enqueues entries related to new host IO commands with newly assigned exchange IDs received thereafter to OQ1209. As long as there are incomplete entries remaining in OQ1229, host IO processing related to OQ1229 and IQ1230 and host IO processing related to OQ1209 and IQ1210 are executed in parallel. After the queue switching instruction, no new entries are enqueued in OQ1229, so eventually there will be no incomplete entries left in OQ1229 and IQ1230.

[0136] Next, the host I / O handover processing program 1400 waits for OQ1229 and IQ1230 to become empty (step S1403: No). If OQ1229 and IQ1230 become empty (step S1403: Yes), the host I / O handover processing program 1400 proceeds to step S1404.

[0137] Next, the host I / O handover processing program 1400 stops the host IF1222 driver running on the CPU 123 of the controller 1221 (step S1404). Stopping the host IF driver here means stopping processing on the host IF control queue. Therefore, stopping the host IF driver does not initialize the host IF, so host link down or similar issues do not occur.

[0138] Next, the host I / O handover processing program 1400 stops the backend processing currently running on the CPU 123 of the controller 1221 (step S1405). Since the data received from the host device is duplicated in memory 104 and 124, even if the backend processing of CPU 123 is stopped, the storage device 1200 can continue to operate as long as CPU 103 is still performing backend processing. As a result, host I / O processing is handed over from controller 1221 to controller 1201.

[0139] Figure 15 is a flowchart illustrating an example of the procedure for resuming host I / O processing in a controller of storage device 1200 that had handed over host I / O processing to the other controller. This processing flow is executed in step S307 of the OS update processing program 300 in Figure 3. Alternatively, it is executed on CPU 103 or CPU 123 of the controller that received a command to resume host I / O processing from the management terminal. Hereafter, this processing flow will be referred to as the host I / O resume processing program 1500. As an example, we will describe the case where controller 1201 has taken over host I / O processing from controller 1221 and then controller 1221 resumes host I / O processing.

[0140] First, the host I / O restart processing program 1500 restarts the host IF1222 driver on the controller 1221's CPU 123 (step S1501). At this time, OQ1229 and IQ1230 are empty, and host I / O processing using them has not yet been performed. Restarting the host IF driver here means restarting processing on the host IF control queue. Therefore, restarting the host IF driver does not initialize the host IF, so host link down or similar issues do not occur.

[0141] Next, the host I / O restart processing program 1500 restarts backend processing on the CPU 123 of the controller 1221 (step S1502).

[0142] Next, the host IO restart processing program 1500 instructs host IF1222 to switch queues (step S1503). Before receiving the queue switching instruction, host IF1222 enqueues entries related to host IO commands received from the host machine to OQ1209. After receiving the queue switching instruction, host IF1222 enqueues entries related to new host IO commands with newly received exchange IDs to OQ1229. As long as there are incomplete entries remaining in OQ1209, host IO processing related to OQ1209 and IQ1210 and host IO processing related to OQ1229 and IQ1230 are executed in parallel. After the queue switching instruction, no new entries are enqueued in OQ1209, so eventually there will be no incomplete entries left in OQ1209 and IQ1210.

[0143] Next, the host I / O restart processing program 1500 waits for OQ1209 and IQ1210 to become empty (step S1504: No). If OQ1209 and IQ1210 become empty (step S1504: Yes), the host I / O restart processing program 1500 proceeds to step S1505.

[0144] Next, the host I / O restart processing program 1500 stops the host IF 1222 driver running on the CPU 103 of the controller 1201 (step S1505). Stopping the host IF driver here means stopping processing on the host IF control queue. Therefore, stopping the host IF driver does not initialize the host IF, so host link down or similar issues do not occur. As a result, host I / O processing is handed over from controller 1201 to controller 1221.

[0145] According to this embodiment, similar to the storage device 100 according to the first embodiment, OS update processing and restart processing can be performed while maintaining the availability of the dual controller and data redundancy. Furthermore, by continuing host I / O processing during the OS restart process, the power consumption required to retransmit I / O requests from the host device during the OS restart process can be reduced.

[0146] As described above, the storage device 1200 according to the second embodiment is characterized by having a host interface to which multiple pairs of OQ and IQ can be assigned. As a result, the core 900 of CPU 103 accesses OQ1209 and IQ1210 in memory 104 directly connected to CPU 103 in order to control the host interface 1222. Similarly, the core 500 of CPU 123 accesses OQ1229 and IQ1230 in memory 124 directly connected to CPU 123 in order to control the host interface 1222. Therefore, compared to the case where OQ and IQ are located in the memory of the other controller, as in the storage device 100 according to the first embodiment, the time required to access OQ, IQ and their queue indices can be reduced. Consequently, the storage device 1200 can reduce the waiting time of cores involved in host I / O processing and improve performance compared to the storage device according to the first embodiment.

[0147] In this embodiment, memory 104 (second memory) has OQ109 and IQ110 as an example of a second control queue for the host interface. The host interface receives a switching instruction specifying either the first control queue (OQ129 and IQ130) or the second control queue (OQ109 and IQ110) as the enqueue destination for requests received from the host device. The host interface then switches the enqueue destination control queue for requests received from the host device, which are assigned an identifier for a series of operations related to the new request to be received from the host device. This provides the same effects as in the first embodiment, and the reliable control queue switching described above allows for continuous processing of I / O requests from the host device before and after the handover described above, as well as ensuring reliability by duplicating the data received from the host device.

[0148] When the operating system restarts, the storage control program, after receiving a switching instruction from the host interface to switch the enqueue destination of requests received from the host device from the first control queue (OQ129 and IQ130) to the second control queue (OQ109 and IQ110), executes a restart process without initializing the OS-unmanaged area 204 (first predetermined area) on the hardware used by the operating system, after the first control queue (OQ129 and IQ130) has become empty. In this way, the same effects as in the first embodiment can be achieved, and as described above, by switching the control queue while confirming that one of the control queues has become empty, it is possible to reliably continue processing I / O requests from the host device before and after the handover described above, and to ensure reliability by duplicating the data received from the host device.

[0149] When the operating system restarts, the storage control program receives a switching instruction from the host interface to switch the enqueue destination of requests received from the host device from the second control queue (OQ109 and IQ110) to the first control queue (OQ129 and IQ130). After the second control queue becomes empty, the CPU 103 (second processor) stops I / O processing with the host device. This achieves the same effects as the first embodiment, ensures that I / O requests from the host device are processed reliably and continuously before and after the above-mentioned handover, and duplicates the data received from the host device to ensure reliability.

[0150] (3) Third Embodiment Referring to Figures 16 and 17, a storage device according to the third embodiment will be described. The configuration of the storage device according to the third embodiment is the same as that of the storage device according to the first embodiment shown in Figures 1 to 11, except for the differences described below, so the explanation of the similarities will be omitted. In this embodiment as well, the process of restarting the OS of the storage device controller at any time will be described using the process of restarting the OS in conjunction with the update process of the controller OS as an example, but it is not limited to this, and for example, the OS of the storage device controller may be restarted when the administrator of the storage device deems it necessary.

[0151] Figure 16 is a diagram illustrating the data transfer path related to host I / O processing before host I / O handover in the storage device 1600. Here, it is assumed that, similar to the storage device 100 in the first embodiment, the host I / O received by the host IF 122 is handed over from controller 1621 to controller 1611.

[0152] Storage device 1600 has the same configuration as storage device 100, except for controllers 1611 and 1621. Controller 1611 connects host IF 102 to CPU 103 via PCIe switch 1612. Similarly, controller 1621 connects host IF 122 to CPU 123 via PCIe switch 1622. PCIe switches 1612 and 1622 are equipped with NTB ports 1613 and 1623, respectively, which are switches with NTB functionality. Furthermore, NTB port 1613 of PCIe switch 1612 and NTB port 1623 of PCIe switch 1622 are connected by an inter-controller link 1631. CPU 103 can access host IF 122 via PCIe switch 1612, inter-controller link 1631, and PCIe switch 1622.

[0153] CPU 123 can access host IF 102 via PCIe switch 1622, inter-controller link 1631, and PCIe switch 1612. Except for these points, controllers 1611 and 1621 have the same configuration as controllers 101 and 121. Note that PCIe switch 1612 can connect multiple host IFs to CPU 103, but only one host IF 102 is shown in Figure 16. Similarly, PCIe switch 1622 can connect multiple host IFs to CPU 123, but only one host IF 122 is shown in Figure 16.

[0154] Here, as an example, we will explain the data transfer path when the CPU 123 core 500 controls the host IF 122 in the controller 1621.

[0155] The host IF122, which receives host I / O from the host device 600, accesses OQ129, IQ130 and their queue indices OQPI and IQCI in memory 124 via the PCIe switch 1622 and the data transfer path 1601 through the CPU 123.

[0156] Furthermore, the host IF122 either stores the data received from the host device 600 in the memory 124 via the data transfer path 1601, or transmits the data stored in the memory 124 to the host device 600.

[0157] Core 500 accesses OQ129, its queue index OQPI, and IQ130 in memory 124 via data transfer path 1602.

[0158] Furthermore, Core 500 accesses OQCI, the queue index for OQ129, and IQPI, the queue index for IQ130, located on Host IF122, via a data transfer path 1603 through PCIe switch 1622.

[0159] Furthermore, Core 500 receives data from the host device 600 and stores it in memory 124, and uses DMA 127 to transfer it from memory 124 to memory 104 of controller 1611 via a data transfer path 1604 that passes through CPU 123, inter-controller link 111, and CPU 103. This allows the data received from the host device 600 to be duplicated in memory 104 of controller 1611 and memory 124 of controller 1621 (the host data duplication process described above).

[0160] Figure 17 illustrates the data transfer path related to host I / O processing after host I / O handover in the storage device 1600. As an example, it illustrates the data transfer path when the core 900 of the CPU 103 belonging to the controller 1611 controls the host IF 122 of the controller 1621.

[0161] The host IF122, which receives host I / O from the host device 600, accesses OQ129, IQ130 and their queue indices, OQPI and IQCI, located in memory 124 via the data transfer path 1701 through the CPU 123.

[0162] Furthermore, the host IF122 either stores the data received from the host device 600 in the memory 124 via the data transfer path 1701, or transmits the data stored in the memory 124 to the host device 600.

[0163] Core 900 accesses OQ129, its queue index OQPI, and IQ130 in memory 124 via a data transfer path 1702 through the inter-controller link 111 and CPU 123.

[0164] Furthermore, Core 900 accesses OQCI, the queue index for OQ129 located on host IF122, and IQPI, the queue index for IQ130, via a data transfer path 1703 that passes through PCIe switch 1612, inter-controller link 1631, and PCIe switch 1622.

[0165] Furthermore, the core 900 receives data from the host device 600 and stores it in memory 124, and uses DMA 107 to transfer it from memory 124 to the controller 101's memory 104 via a data transfer path 1704 that passes through CPU 123, the inter-controller link 111, and CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of controller 1611 and the memory 124 of controller 1621 (the host data duplication process described above).

[0166] The operation of the other storage devices 1600 is the same as that of the storage device 100 according to the first embodiment, so their description will be omitted.

[0167] As described above, the storage device 1600 according to the third embodiment is characterized in that the CPU 103 of the controller 1611 accesses the host IF 122 of the controller 1621 via the inter-controller link 1631 to control host I / O processing. According to this embodiment, OS update processing and restart processing can be performed while maintaining the availability of the dual controllers and data redundancy, without using the CPU's P2P data transfer path as in the storage device 100 according to the first embodiment. In addition, by continuing host I / O processing during the OS restart process, the power consumption required to retransmit I / O requests from the host device during the OS restart process can be reduced.

[0168] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are explained in detail for a better understanding of the present invention, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is possible to add configurations from other embodiments to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations. In addition, some or all of the above configurations, functions, processing units, processing means, etc., may be implemented in hardware, for example, by designing them as integrated circuits. Furthermore, each of the above configurations, functions, etc., may be implemented in software by having a processor interpret and execute a program that realizes each function. Information such as programs, tables, files, etc., that realize each function can be stored in storage devices such as non-volatile semiconductor memory, hard disk drives, SSDs, etc., or in computer-readable non-temporary data storage media such as IC cards, SD cards, DVDs, etc. Furthermore, control lines and information lines are shown only if they are considered necessary for explanation, and not all control lines and information lines are necessarily shown in the product. In practice, it can be assumed that almost all configurations are interconnected. Furthermore, in this embodiment, each element described in parallel may be configured such that at least one of the elements is connected in series with respect to the other elements. [Industrial applicability]

[0169] This invention can be applied to a storage device relating to a technology in which a processor controls the host interface and performs data input / output processing in response to I / O requests from a host device. [Explanation of Symbols]

[0170] 100, 1200, 1600... Storage devices, 101, 121, 1201, 1221, 1611, 1621... Controllers, 102, 122, 1202, 1222... Host interfaces, 103, 123... CPUs, 104, 124... Memory, 105, 125... Multiple cores, 111, 1211, 1631... Inter-controller links, 141, 161, 1612, 1622... PCIe switches, 140... Drive boxes, 108, 128... Opaque bridges, 109, 129, 1209, 1229... Outbound queues, 110, 130, 1210, 1230... Inbound queues, 500, 900... Cores

Claims

1. A first controller includes a first processor that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a first memory having a storage area used by the first processor. A second controller comprising at least one second controller including a second processor that controls data input / output processing in response to requests from the host device via a host interface that controls the communication protocol with the host device, and a second memory having a storage area used by the second processor, A controller link connecting the first controller and the second controller, A storage device comprising, The first processor executes an operating system and a storage control program that controls data input / output processing in response to requests from the host device. The storage control program, A configuration unit that assigns a virtual address to a first predetermined area in the first memory where the operating system does not assign a virtual address, and places a first control queue in the first predetermined area where input / output processing data via the host interface is temporarily stored, During the restart process that restarts the aforementioned operating system, A handover unit that transfers the input / output processing from the first processor to the second processor and releases the allocation of virtual addresses to the first predetermined area, A restart unit that performs a restart process to restart the operating system without initializing the first predetermined area on the hardware used by the operating system, After the restart process is completed, a processing restart unit reassigns a virtual address to the first predetermined area and restarts the input / output processing by the first processor. A storage device characterized by being a program for causing the first processor to function.

2. The second processor is, The host interface is accessed via a data transfer path through the inter-controller link. The storage device according to feature 1.

3. The aforementioned data transfer path is The data transfer path includes passing through two ports provided by the first processor, The storage device according to feature 2.

4. The second processor is, The first control queue is accessed via a data transfer path through the inter-controller link. The storage device according to feature 1.

5. The first processor and the second processor each include a DMA (Direct Memory Access), Before the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by the first processor's DMA data transfer from the first memory to the second memory. After the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by the DMA of the second processor transferring data from the first memory to the second memory. The storage device according to feature 1.

6. The storage control program, During the restart process of the operating system, a stop unit stops the process by which the first processor writes data received from the host device, which is stored in the first memory, to the storage medium. The storage device according to claim 1, characterized in that it is a program for causing the first processor to function.

7. The second memory is, It has a second control queue for the host interface, The aforementioned host interface is A switching instruction is received from the host device to specify either the first control queue or the second control queue as the enqueue destination for the request received from the host device. Next, the control queue to which the enqueue is to be switched is determined based on the request received from the host device, which is assigned an identifier for a series of operations related to the new request received from the host device. The storage device according to feature 1.

8. The storage control program, During the restart process of the aforementioned operating system, The host interface, after receiving the switching instruction to switch the enqueue destination of the request received from the host device from the first control queue to the second control queue, and after the first control queue becomes empty, includes an execution unit that performs a restart process without initializing the first predetermined area on the hardware used by the operating system, The storage device according to claim 7, characterized in that it is a program for causing the first processor to function.

9. The storage control program, During the restart process of the aforementioned operating system, After the host interface receives the switching instruction to switch the enqueue destination of the request received from the host device from the second control queue to the first control queue, and after the second control queue becomes empty, A stop unit that stops the input / output processing with the host device by the second processor, The storage device according to claim 8, characterized in that it is a program for causing the first processor to function.

10. The aforementioned restart process is This process involves restarting the operating system after it has been updated, following the update process of the aforementioned operating system. The storage device according to feature 1.

11. A first controller includes a first processor that controls data input / output processing in response to requests from a host device via a host interface that controls a communication protocol with the host device, and a first memory having a storage area used by the first processor. A second controller comprising at least one second controller including a second processor that controls data input / output processing in response to requests from the host device via a host interface that controls the communication protocol with the host device, and a second memory having a storage area used by the second processor, A controller link connecting the first controller and the second controller, A method for restarting a storage device comprising: The first processor executes an operating system and a storage control program that controls data input / output processing in response to requests from the host device. The storage control program, The arrangement step involves assigning a virtual address to a first predetermined area in the first memory where the operating system does not assign a virtual address, and arranging a first control queue in the first predetermined area where data for input / output processing via the host interface is temporarily stored. During the restart process that restarts the aforementioned operating system, A handover step in which the input / output processing is handed over from the first processor to the second processor and the allocation of virtual addresses to the first predetermined area is released, A restart step that performs a restart process to restart the operating system without initializing the first predetermined area on the hardware used by the operating system, After the restart process is completed, a process restart step is performed in which a virtual address is reassigned to the first predetermined area and input / output processing by the first processor is resumed. A method for restarting a storage device, characterized by causing the first processor to execute the following.

12. The first processor and the second processor each include a DMA (Direct Memory Access), Before the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by the first processor's DMA data transfer from the first memory to the second memory. After the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by the DMA of the second processor transferring data from the first memory to the second memory. A method for restarting a storage device according to feature 11.

13. The storage control program, During the restart process of the operating system, the process by which the first processor writes data received from the host device, which is stored in the first memory, to the storage medium is stopped. The method for restarting a storage device according to claim 11, characterized in that the first processor is made to perform the following action.

14. The second memory is, It has a second control queue for the host interface, The aforementioned host interface is A switching instruction is received from the host device to specify either the first control queue or the second control queue as the enqueue destination for the request received from the host device. Next, the control queue to which the enqueue is to be switched is determined based on the request received from the host device, which is assigned an identifier for a series of operations related to the new request received from the host device. A method for restarting a storage device according to feature 11.

15. The storage control program, During the restart process of the aforementioned operating system, After the host interface receives the switching instruction to switch the enqueue destination of the request received from the host device from the first control queue to the second control queue, and after the first control queue becomes empty, it performs a restart process that does not involve initializing the first predetermined area on the hardware used by the operating system. The method for restarting a storage device according to claim 14, characterized in that the first processor is made to perform the above action.

16. During the restart process of the aforementioned operating system, After the host interface receives the switching instruction to switch the enqueue destination of the request received from the host device from the second control queue to the first control queue, and after the second control queue becomes empty, The input / output processing with the host device by the second processor is stopped. The method for restarting a storage device according to claim 15.

17. The aforementioned restart process is This is a restart of the operating system after it has been updated in accordance with the operating system update process. A method for restarting a storage device according to feature 11.

Images