Method and system for obtaining cache resources for expected writes

Abstract

A computer program product, system, and method are provided for prefetching cache resources for write requests from a host to tracks in a storage device that are cached in a cache. Prior to receiving an anticipated write to a plurality of tracks in a write set, cache resources held for the tracks in the write set are released. After the cache resources are released, cache resources for the tracks in the write set are obtained for anticipated write requests to the tracks in the write set.

Description

Technical Field

[0001] The present invention relates to a computer program product, system, and method for obtaining cache resources for expected writes to tracks in a write set after releasing cache resources for tracks in a write set. Background Technology

[0002] In a storage environment, the host system can first transmit read / write requests to the connected storage system via a fast channel (such as a bus interface or a High Speed ​​Peripheral Component Interconnect (PCIe) interface). For a read / write request on the fast channel (which should complete within a threshold time), the host system keeps the application thread for the read / write request in a spin loop, waiting for the request to complete. This saves processor time associated with context switching, which responds to interrupts that deactivate and reactivate threads upon receiving a response to a read / write request. If the data for the read / write request sent on the fast channel is not in the cache, the storage system can cause the read / write request to fail, and the host system can transmit the same read / write request over the storage area network via the host adapter, which is slower than processing I / O requests via a bus (e.g., a PCIe interface). Transmitting read / write requests on a second channel requires the host system to perform a context switch from handling the read / write request to another task while waiting for the read / write request to complete. Context switching is expensive because it requires the processor running the task to clear all registers used for the new task, as well as the L1 and L2 caches. Then, when the new task is completed, the context-switched task is reactivated and the status data is returned to the registers used for the context-switched task, as well as the L1 and L2 caches, while waiting for read / write requests to complete.

[0003] Certain read / write operations need to complete within a threshold time; otherwise, they fail. To process read or write requests, the storage system must allocate cache resources (including resources and segments within the cache storage device) and access track metadata to process the request. Track metadata provides information about the data format and record layout within the track, which is required to perform reads and writes to the track. However, allocating cache resources from the storage device (including accessing metadata) constitutes a significant portion of the latency in processing read / write requests.

[0004] What is needed in this field is improved technology for prefetching cache resources for host write requests to the cache on the fast track, so that cache resources for the track are available when a write request to the track is received on the fast track. Summary of the Invention

[0005] A computer program product, system, and method are provided for prefetching cache resources in response to write requests from a host to tracks cached in a storage device. Before receiving anticipated writes for multiple tracks in a write set, cache resources held for the tracks in the write set are released. After releasing the cache resources, cache resources for the tracks in the write set are obtained for the anticipated write requests to the tracks in the write set.

[0006] Using the above embodiments, releasing cached resources for tracks in the write set makes those resources available for other requests, which is optimal if expected writes to tracks in the write set cannot be performed (e.g., if access to the write set is paused due to events such as volume invalidation caused by prolonged busy periods, unsupported replication service status, or other processes). Reacquiring cached resources for the tracks for which cached resources have been released after releasing them increases the likelihood that write requests sent by the host to the write set will be completed within the required threshold time, which is especially important for performance if the host thread is spinning on write request tasks for those write requests.

[0007] In a further embodiment, for write requests received from the host on the first channel, the cache resource is held for the write set. For cache resources in the write set that are unavailable on a track, a first write request received on the first channel fails. A second write request for a track sent by the host in response to the first write request failure received on the first channel is received from the host on the second channel. Obtaining the cache resource includes: estimating the number of writes the host may have sent on the second channel since the cache resource was released; determining a starting track, the starting track being the estimated number of writes after a cursor pointing to a track in the write set where prefetching of cache resources begins after the cache resource was released; and obtaining cache resources for sequential tracks in the write set starting from the starting track.

[0008] Using the above embodiments, the number of writes that the host may have already performed on the second channel is estimated, allowing prefetching of tracks estimated to have been written on the second channel to be skipped, since cache resources are no longer needed for those tracks. Thus, prefetching is optimized by starting prefetching from the first track in the write set that may not have been written by write requests sent on the second channel after a pause.

[0009] In a further embodiment, for a write request received from the host on the first channel, the cache resources are held for the write set. For a track in the write set where the cache resources are unavailable, the first write request received on the first channel returns a failure. A second write request for a track, sent by the host in response to the failure of the first write request received on the first channel, is received from the host on the second channel. The second write request identifies the write set, wherein cache resources in the write set are obtained for sequential tracks starting from the track following the track written by the second write request.

[0010] Using the above embodiments, obtaining cache resources for tracks to follow tracks written by the second write request on the second channel avoids prefetching tracks that have already been written on the second channel, because the host is unlikely to retry tracks on the first channel that have been successfully written on the second channel.

[0011] In a further embodiment, in response to receiving a second write request identifying the write set on the second channel, a last retry track field for the write set is set to indicate the last track written by the second write request. The cache resource is obtained from the track following the track indicated in the last retry track field.

[0012] Using the above embodiment, cache resources are prefetched after the last track written on the second channel because the host may not attempt to re-access tracks on the first channel that have already been accessed on the second channel. Thus, recording the last written track allows cache resources to be prefetched to follow the last written track, ensuring that cache resources are only available for tracks that are likely to be written on the first channel, avoiding the acquisition of cache resources for tracks that will not be written.

[0013] In a further embodiment, the second write request also indicates whether the first write request will be retried on the first channel. In response to the second write request indicating that the first write request will not be retried, the cache resource is obtained from the track following the track written by the second write request. In response to the second write request indicating that the first write request will be retried, cache resources are obtained for sequential tracks in the write set starting from the track written by the second write request.

[0014] Using the above embodiments, the host provides a hint regarding whether a failed write request retried on the second channel will also be retried on the first channel. This hint allows for optimization by prefetching cache resources from the track written on the second channel, since the host will also retry the write on the first channel, making cache resources available for write requests on the first channel to allow the first channel write to complete.

[0015] A computer program product, system, and method are provided for sending requests to a storage controller that manages access to tracks in a storage device. A first write request for a track in a write set is sent to the storage controller on a first channel. Before receiving the write request for the track in the write set, cache resources for the track in the write set are pre-allocated by the storage controller. A failure is received from the storage controller in response to the first write request. In response to the failure of the first write request, a second write request is sent on a second channel for the track written by the first write request. The second write request instructs the write set such that the storage controller obtains cache resources for the track in the write set that follows the track indicated in the second write request. The obtained cache resources are used for the anticipated write request for the track in the write set to be sent on the first channel.

[0016] In a further embodiment, the second write request indicates whether the first write request will be retried on the first channel. In response to the second write request indicating that the first write request will be retried on the second channel, the storage controller obtains cache resources from the track written by the first write request.

[0017] Using the above embodiments, the host can specify to the storage controller whether it will retry write requests on the first channel, allowing the storage controller to adjust the prefetch to the order of the last written track in the write set without retrying the write request. Furthermore, if the host will retry a write request written on the second channel on the first channel, this indication to retry the write request on the second channel ensures that cache resources for the tracks written by the second channel write request are available for use during the first channel write request. Additionally, in the case of retrying a write request on the second channel, the last retry track field is not set to indicate the track last written by the write request, thereby obtaining cache resources for those tracks retried on the second channel. This optimizes the prefetch operation by adjusting the prefetch as needed to avoid prefetching cache resources for write tracks that will not be rewritten by write requests on the first channel, so that cache resources are not needed when they are not required for retrying writes on the first channel. Attached Figure Description

[0018] Figure 1 An embodiment of the storage environment is shown;

[0019] Figure 2 An example of write set information for an established write set is shown;

[0020] Figure 3 An example of a track access list entry in a track access list is shown;

[0021] Figure 4 An embodiment of a second-channel write request is shown, which is sent on the second channel to retry a write request that failed on the first channel;

[0022] Figure 5 An example of handling pauses in operations on a write set is shown;

[0023] Figure 6 An example of handling the termination of a pause on a write set is shown;

[0024] Figure 7 , 8 9 and 12 illustrate an embodiment of the operation of obtaining cache resources for the expected write request on the first channel when the pause in the write set ends;

[0025] Figure 10 An embodiment of an operation performed by a host system to generate a second channel write request to the storage system to retry a failed write request sent on the first channel to write to the track is illustrated.

[0026] Figure 11 An embodiment of the operation performed by the storage system to process a second-channel write request from the host is illustrated;

[0027] Figure 13 An embodiment of a computer architecture used in conjunction with the described embodiments is shown. Detailed Implementation

[0028] If an event exists that would prevent write access to a track for an extended period to allow other processes to access tracks held for the write set (such as volume invalidation due to prolonged busy periods, unsupported replication service status, or other processes), access to the write set can be paused. Pausing access to tracks in the write set causes cache resources used for writing to be released. If no cache resources were pre-allocated for these write requests when the first channel write request was received, releasing cache resources will cause these requests to fail in retrying to write to tracks in the paused write set.

[0029] By accessing the cache resource on the first channel after an event that causes the cache resource to be released (e.g., a pause in the write set), and before the write request, the latency for processing the access request is minimized. Furthermore, by accessing the cache resource before the access request, the described embodiment increases the likelihood that a write request sent by the host on the first fast channel will complete within the required threshold time for processing access requests on the first channel that require fast processing. This keeps the spin time of the host thread on the write request task for the write request sent on the bus interface within an acceptable time threshold. However, if the cache resource for the requested target track has not been allocated before the request, the write request resent on the first channel after being released due to a pause in other operations may fail again, because it is unlikely that the write request will complete within the threshold time, assuming that the cache resource must be allocated. A write request failure on the first channel causes the host to re-drive the write request on the second channel. Processing the write request on the second channel when the access request is processed will allocate the required cache resource.

[0030] The described embodiments provide improvements to computer technology for prefetching cache resources by reclaiming cache resources that have been released due to pauses or other processes for use on tracks in the write set. The described embodiments use techniques to estimate where a write request on the first channel will begin if the host retryes a failed write request on the second channel. In this way, the storage system optimizes prefetching cache resources by reclaiming cache resources for tracks in the write set that may be written by subsequent write requests on the first channel, and avoids reclaiming cache resources for tracks in the write set that will not be accessed again by write requests on the first channel.

[0031] Figure 1An embodiment of a storage environment is illustrated, in which a host 100 directs read and write requests to a storage system 102 (also referred to as a storage controller, control unit, or server) to access tracks in a volume configured in a storage device 104 within a disk enclosure 106. The host 100 includes a processor complex 108 of one or more processor devices and a memory 110 containing an operating system 111 executed by the processor complex 108. The host operating system 111 generates read and write requests for tracks configured in the storage device 104. The host 100 includes hardware for transmitting read and write requests over two distinct channels. The “first channel” may include a bus interface (e.g., a Fast Peripheral Component Interconnect (PCIe)) including a bus 112, a bus switch 114 for connecting one or more devices on the bus 112, the one or more devices including the processor complex 108, the memory system 110, and a bus host adapter 116 for extending the bus interface to the storage system 102 via an external bus interface cable 118. Additional bus interface technologies can be used to extend the bus interface, including PCIe extender cables or components (such as distributed PCIe switches) to allow PCIe over Ethernet, for example, using ExpEther technology.

[0032] A "second channel" connecting host 100 and storage system 102 can use a network host adapter 120 connected to bus 112, which is connected to a separate network 122 through which host 100 and storage system 102 communicate additionally. The first channel via the bus interface can include a faster access channel than the second channel using the network 122 interface via network host adapter 120.

[0033] Storage system 102 includes a bus interface comprising buses 124a and 124b, a bus switch 126 connected to endpoint devices on buses 124a and 124b, and a bus host adapter 128 connected to an external bus interface cable 118 to allow communication with host 100 on the bus interface via a first channel. Storage system 102 includes an input / output bay 130 having the bus host adapter 128, one or more device adapters 132 connected to storage device 104, and one or more network host adapters 134 connected to network 122 and the host system.

[0034] Storage system 102 includes a processor complex 136 with one or more processor devices and a memory 138 with a cache 140 to cache tracks accessed by a connected host 100. Memory 138 includes a write access manager 142 and a storage manager 144 for managing write requests to the cache 140. Storage manager 144 manages access requests to tracks in storage device 104 from processes in host 100 and storage system 102. Devices 136, 138, 128, 132, and 134 are connected via a bus interface implemented in bus channels 124a, 124b and bus switch 126.

[0035] The write access cache manager 142 prefetches cache resources (including metadata) in the cache 140 for a defined write set, wherein host write requests for the defined write set are expected on the first channel, so that such write requests can be completed quickly with low latency.

[0036] Tracks may include any data units (e.g., tracks, logical block addresses (LBAs), etc.) configured in storage device 104 that are part of a larger track group (e.g., volumes, logical devices, etc.).

[0037] Write access manager 142 maintains cache management information 146 in memory 138 to manage read (unmodified) and write (modified) tracks in cache 140. Cache management information 146 may include a track index 148 providing an index of tracks in cache 140 to cache control blocks in control block directory 150; and a least recently used (LRU) list 152 of tracks in cache 140. Control block directory 150 includes cache control blocks, wherein one cache control block exists for each track in cache 140, providing metadata about the track in cache 140. Track index 148 associates a track with the cache control block providing information about the track in cache 140. When it is determined that cache LRU list 152 is full or has reached a threshold level, a track is degraded from LRU list 152 to make room for more tracks to be staged from storage device 104 into cache 140.

[0038] The cache management information 146 may also include write set information 200, which is established by the host 100 for track write sets to be written on the first channel. The write access manager 140 may prefetch cache resources for tracks in the write sets before receiving write transactions. The host 100 may establish multiple write sets for multiple track ranges and allocate track resources to these multiple track ranges if multiple sequential write transactions are expected to flow to different track ranges.

[0039] The host operating system 111 can establish a write set 200 for track range 204 before sending write requests for sequential write transactions, so that the write access manager 142 pre-allocates cache resources for that write set if sequential write transactions are expected to be directed to those tracks indicated in the write set soon. These pre-allocated cache resources reduce the latency when sequential write requests are finally received. Furthermore, by allocating cache resources to a finite (fixed number) first subset of tracks within the write set, cache resources are maintained only for those tracks most likely to be written as part of a sequential write stream. Additionally, the number of tracks for which cache resources are maintained is limited to allow these cache resources to be accessed by other processes in the host operating system 111 or other connected hosts 100.

[0040] The cache resources maintained and accessed for the tracks in track range 302 may include segments in cache 140 for writing to the tracks, segments in non-volatile storage if a copy of the track to be written is to be stored in non-volatile storage in the same or a different cluster, track metadata for the tracks, and other types of cache resources required to process write transactions to the tracks.

[0041] In a particular embodiment, there may be multiple hosts 100 connected to the storage system 102 via a first channel and a second channel to access tracks in the storage device 104. In this case, the storage system 102 will have at least one bus host adapter 128 to connect to the bus interface 118 of each connected host 100, and one or more network host adapters 134 to connect to the network host adapter 120 on the host 100.

[0042] In one embodiment, bus interfaces 112, 114, 116, 118, 124a, 124b, 126, and 128 may include Fast Peripheral Component Interconnect (PCIe) bus interface technology. In an alternative embodiment, bus interfaces 112, 114, 116, 118, 124a, 124b, 126, and 128 may utilize a suitable bus interface technology other than PCIe. Bus host adapters 116 and 128 may include PCIe host adapters that provide interfaces for connection to PCIe cable 118. Network 122 may include a Storage Area Network (SAN), Local Area Network (LAN), Wide Area Network (WAN), Fibre Channel (FICON®), Internet, Intranet, etc., and network host adapters 120 and 134 provide network 122 connectivity between host 100 and storage system 102. (FICON is a registered trademark of IBM worldwide.)

[0043] Storage system 102 may include storage systems (also referred to as control units and storage controllers), such as IBM® DS8000® and DS8880 storage systems, or storage controllers and storage systems from other vendors. (IBM and DS8000 are trademarks of IBM worldwide). Host operating system 111 may include an operating system such as the Z Systems operating system (Z / OS®) from IBM (“IBM”) or other operating systems known in the art. (Z / OS is a registered trademark of IBM worldwide).

[0044] The storage device 104 in the disk enclosure 106 may include different types or categories of storage devices, such as magnetic hard disk drives, solid-state storage devices (SSDs) composed of solid-state electronic components, EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, flash disks, random access memory (RAM) drives, storage class memory (SCM), phase-change memory (PCM), resistive random access memory (RRAM), spin-transfer torque memory (STT-RAM), conductive bridged RAM (CBRAM), magnetic hard disk drives, optical discs, magnetic tapes, etc. Volumes in the storage space can also be configured from device arrays (e.g., jigsaw disks (JBODs), direct access storage devices (DASDs), redundant arrays of independent disks (RAID) arrays, virtualization devices, etc.). Furthermore, the storage device 104 in the disk enclosure 106 may include heterogeneous storage devices from different vendors and different types of storage devices, such as a first type of storage device (e.g., a hard disk drive) with a slower data transfer rate than a second type of storage device (e.g., an SSD).

[0045] Figure 2 Write set information 200 is shown for the established write set to receive write requests on the first channel. i An implementation of an instance of [the instance], writing collection information 200. i Includes: a write set identifier (ID) 202, which provides a unique identifier for the write set; a track range 204, for which sequential write transactions are expected on the first channel and for which cache resources should be accessed before sequential write transactions; and a track access list 300, which indicates for each track in the track range 204 whether cache resources are held for that track and since the establishment of the write set 200. i This involves checking whether the track has been written to; prefetching cursor 206, which indicates track 302 within the track range, from which cache resources should be allocated for sequential write transactions in write set 202; finally, releasing track field 208, which, in the implementation... Figure 7In the embodiments, it is used to indicate the last track for which cache resources are released; and the last retry track field 210, which is used in Figure 10 , 11 Used in embodiments 1 and 2, and includes by means of a second channel ( Figure 1 The write request sent on components 120, 122, and 134 writes to the track in track range 204.

[0046] In a particular embodiment, the prefetch cursor 206 may be set during normal processing to point to the track that the write access manager 142 expects the host 100 to be writing to (if actively writing) or to be writing to next (if not actively writing). The prefetch cursor 206 points to the write access manager 142 to determine the position of the host 100 in their processing.

[0047] Figure 3 The track access list entry 300 in track access list 300 is shown. i In one embodiment, track access list entries 300 i Indicators: Track identifier (ID) 302; cache resource retention flag 304, which indicates whether cache resources are being retained for track 302; and track write flag 306, which indicates whether track 302 has been written since the write set 202 was established.

[0048] Figure 4 An embodiment of a second channel write request 400 received from host 100 on a second channel is shown. The second channel write request 400 includes: a write opcode 402; a defined extent range 404 to which a subset of tracks to which one or more subsequent sequential write transactions 406 in the write set 408 will be directed; and a retry flag 410 on the first channel, indicating whether the write transaction 406 in the second channel write request 400 will be subsequently retried on the faster first channel.

[0049] Figure 5 An embodiment of operations performed by write access manager 142 for handling pauses in write sets is shown. Pauses can be caused by the volume including the write set becoming unqualified, the lack of input / output (I / O) activity on the track associated with the write set for an extended period of time, the presence of copy operations (e.g., duplication, mirroring, etc.) to the volume including the write set, or other reasons for pausing the write set. During processing (in block 500) of write set 200... i During the pause, write access manager 142 targets write collection 200 i The track access list 300 determines (in block 502) the tracks in the write set that have allocated cache resources, such as those used for write set 200. iTrack access list entry 300 in track access list 300 i As indicated in field 304. Relative to the determined track, release (in box 504) the cached resources. Write access manager 142 to update (in box 506) the track access list entry 300 for all tracks for which cached resources have been released. i This indicates that a 304 cached resource is not being maintained. Figure 7 In this embodiment, the last released track field 208 is set (in box 508) to be written to the last track in the set for which cached resources have been released. Figure 11 and 12 In one embodiment, the final retry track 210 is set (in block 510) to empty, thereby indicating that no writes have been made to the track since the pause ended.

[0050] use Figure 5 In this embodiment, when a pause is handled on a track in the write set, the cache resources used for those tracks in the write set are released so that they can be used by other cache operations. If writes on the first channel continue toward that write set, cache resources will need to be retrieved again from prefetch cursor 206.

[0051] Figure 6 An embodiment of the operation of ending a pause in the write set by the processing performed by the write access manager 142 is shown. According to Figure 7 , 8 In one of the embodiments of 9 and 12, at the end of the processing (in box 600) pause, the write access manager 142 obtains (in box 602) cache resources for sequential tracks from the prefetch cursor 206 for anticipated write requests to tracks in the write set. The prefetch cursor 206 can be set before the pause during a normal track prefetch operation expected to perform write transfers from host 100. The write access manager 142 sets field 304 ( Figure 3 The track access list 300 indicates (in block 604) all tracks for which cache resources are accessed / held, with track 302 holding cache resources. The prefetch cursor 206 is set (in block 606) to point to the starting point of the track for which cache resources have been acquired, allowing prefetching of freed cache resources.

[0052] use Figure 6In this embodiment, after a pause on the write set ends, cache resources are acquired for the tracks in that write that are expected to receive other writes on the first channel. Prefetching begins from the prefetch cursor 206, which was set before the pause during normal track prefetching. In this way, the prefetch cursor points to the start of the track for which cache resources have been freed. Acquiring cache resources before receiving write requests on the first channel allows write requests to continue, because transactions can be processed very quickly with acceptable latency using pre-allocated cache resources.

[0053] If cache resources are not allocated to allow for low latency processing of write requests, the write request fails because the transaction is unlikely to complete within the fast time threshold. This determination is made to avoid host latency caused by the host processor spinning on a thread processing a write request while waiting for it to complete. If cache resources are pre-allocated, the write is likely to complete on the first channel within the latency threshold required to prevent the host processor from holding threads for too long (which would cause other I / O requests to be queued and delayed). Returning a failure when cache resources are not pre-allocated causes the host thread waiting for the write request task to be deactivated, and the host processor can context switch to process other tasks, then retry the write request on the second network channel during the context switch.

[0054] Furthermore, using the described embodiments, once the write request is completed, the cache resources held for the target track can be released, and then the cache resources for the next track in the track range can be accessed.

[0055] Figure 7 This illustrates the process performed by the write access manager 142 for... Figure 6 An example of the prefetch operation at box 602. Initiated (at box 700). Figure 6 After the prefetch operation at box 602 obtains the cache resources for the first channel write request, write access manager 142 obtains (in box 702) the resources for writing collection 200. i The cached resources of the tracks from prefetch cursor 206 to the last track 208 that was freed.

[0056] use Figure 7 In one embodiment, the write access manager 142 obtains the information for use in box 504 ( Figure 5 The cached resources of all tracks are released at this location to allow writing to the write set to continue on the fast first channel after the pause ends.

[0057] Figure 8 This demonstrates the execution performed by the write access manager 142 to perform... Figure 6 An example of the prefetch operation at block 602. Initiated (at block 800). Figure 6 After the prefetch operation at block 602 obtains the cache resources for the first channel write request, write access manager 142 obtains (at block 802) the resources for writing set 200. i The cached resources are a fixed number of sequential tracks after the prefetch cursor 206.

[0058] use Figure 8 In one embodiment, assuming the host 100 will retry a write request on the second channel for the first track in the track identified by the prefetch cursor 206 for which cache resources have been released, the write access manager 142 obtains resources for a fixed number of tracks starting from the track pointed to by the prefetch cursor. By skipping the track identified by the prefetch cursor 206 or skipping the tracks in the write set for which cache resources have been released, the write access manager 142 avoids prefetching cache resources for tracks that the write request sent on the second channel might have already been written to after the write request failed on the first channel.

[0059] Figure 9 This illustrates the number of writes that host 100 may have sent on the second channel since the cache resource was released as part of a pause in the write set, as estimated by write access manager 142. Figure 6 An example of the prefetch operation performed at box 602. Initiated (at block 900). Figure 6 After the prefetch operation at block 602 obtains cache resources for the first channel write request, write access manager 142 determines (at block 902) the second channel write time on the second channel when the host completes the write request. This second channel write time can be a preset value or an average of the times when the most recent second channel write request was completed. Write access manager 142 estimates (at block 904) the number of writes performed by the host on the second channel during the pause period, based on the pause time and the second channel write time (e.g., pause time divided by the second channel write time). The start track is determined (at block 906) as the number of tracks including the estimated number of writes following prefetch cursor 206. Prefetch cursor 206 is then set (at block 908) to the start track. Write access manager 142 obtains (at block 910) cache resources for a fixed number of tracks starting from the prefetch cursor (including the track at prefetch cursor 206).

[0060] use Figure 9In one embodiment, the write access manager 142 estimates the number of writes the host may have already performed on the second channel to skip obtaining cache resources for those tracks estimated to have been written to on the second channel during the pause, since cache resources are no longer needed for those tracks written to on the second channel. Thus, Figure 9 The implementation optimizes prefetching by starting prefetching from the first track in the write set that may not have been written by write request 400 sent on the second channel after a pause.

[0061] Figure 10 , 11 Figures 1 and 12 illustrate an embodiment in which host 100 retryes a write request that failed on the first channel on the second channel by encoding a write request on the second channel with information about where the write access manager 142 can begin prefetching (including write set ID 408 and retry flag 410 on the first channel).

[0062] Figure 10 This illustrates the write set 200 received from storage system 102 and transmitted on the first channel. i This is an embodiment of the operation performed by the host 100 operating system 111 after a write request for a track fails. Upon receiving (in block 1000) a failure, the host 100 generates (in block 1002) a write request 400 on the second channel for the track written by the failed write request on the first channel. The write set field 408 indicates (in block 1004) the write set 200 of the tracks to be rewritten on the second channel. i If (in block 1006) host 100 is configured to retry write request 400 on the first channel, then (in block 1008) the retry flag 410 on the first channel is set to indicate that write request 400 will be retried on the first channel. If (in block 1006) write request 400 is not retried on the first channel, then (in block 1010) the retry flag 410 on the first channel is set to indicate that write request 400 will not be retried on the first channel. After flag 410 is set in block 1008 or 1010, write request 400 is sent (in block 1012) to storage system 102 on the second channel.

[0063] Figure 11An embodiment is illustrated in which the write access manager 142 of storage system 102 processes an operation of a write request 400 from host 100 on a second channel during a pause in writing to a write set. Upon receiving a write request 400 on the second channel (in block 1100), the write access manager 142 determines (in block 1102) whether the write request 400 indicates a write set 408 established for a write request on the first channel. If (in block 1102) no write set 408 is indicated, the second write request is processed (in block 1104). If (in block 1102) a write set 408 is indicated, and the retry flag 410 on the first channel indicates (in block 1106) that the write request failed on the first channel and caused the received write request 400 to not be retried on the first channel, the last retry track field 210 for write set 408 is set (in block 1108) to the track following the track (or the last track) written by the write request 400. If (in block 1106) the retry flag 410 on the first channel indicates that the write request will be retried on the first channel, or after setting (in block 1108) the last retry track field 210, the second write request 400 is processed (in block 1104) to write to the track in the write set.

[0064] Figure 12 This illustrates the execution of write access by write access manager 142 on write set 200. i After the pause in the access ends, prefetching is used to write to set 200. i An embodiment of the operation of cache resources for tracks in the block. After initiating a prefetch operation (in block 1200), if the Last Retry Track field 210 indicates a track (in block 1202), the prefetch cursor 206 is set to the track indicated in the Last Retry Track field 210. If the Last Retry Track field 210 does not indicate a track (in block 1202) or after setting the prefetch cursor 206 (in block 1204), the write access manager 142 obtains cache resources for writing a fixed number of sequential tracks in the set starting from the prefetch cursor 206.

[0065] use Figure 10 , 11In the embodiment of 12, if write request 400 will also be retried on the first channel, write access manager 142 must also obtain cache resources for the track written by write request 400 to successfully process the first channel write request. To ensure that cache resources for the track written by second channel write request 400 are obtained, the last retry track field 210 is not set to indicate the track last written by write request 400, such that cache resources are obtained from the current prefetch cursor position 206. If write requests will not be retried on the first channel, write access manager 142 does not need to prefetch cache resources for the track written by second channel write request 400. In this case, to skip the prefetching of the track just written, the last retry track field 210 is set to follow the track last written by write request 400, such that write access manager 142 will begin prefetching from the track following the track written by second channel write request 400 in the write set after the pause.

[0066] use Figure 10 , 11 In embodiments 1 and 12, host 100 can specify to write access manager 142 whether the host will retry a write request on the first channel, allowing write access manager 142 to adjust prefetch cursor 206 to the sequential track in the write set following the last written track without retrying the write request. This optimizes prefetching operations by adjusting prefetch cursor 206 as needed to avoid prefetching cache resources for write tracks that will not be accessed by write requests on the first channel, thus eliminating the need to acquire cache resources.

[0067] In one embodiment, the second channel includes a Fibre Connectivity (FICON®) link, a proprietary name for IBM's ANSI FC-SB-3 Single-Byte Command Code Set-3 Mapping Protocol for Fibre Channel (FC), the first channel includes IBM zHyperLink, and the host operating system 111 includes Z / OS®. The host 100 can then associate FICON IO with write set 408 by retrying failed HyperLink (first channel) writes via the FICON interface (second channel) by adding new fields such as a retry write flag 410 on the first channel and a write set ID 408. This additional information allows the write access manager 142 to set write set information 200 for a specific track. iThe last retry track field 210 in the data. When the write set pause is complete, the host 100 will begin to reacquire tracks after the last retry track 210. The host 100 may also have software hints to inform the storage system 102 that the host will retry the write on zHyperLink (first channel) to control where the storage system 102 directs prefetching.

[0068] This invention can be implemented as a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0069] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0070] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or downloaded via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network) to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0071] Computer-readable program instructions for performing the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from the computer-readable program instructions.

[0072] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0073] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0074] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0075] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a non-consecutive order as shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0076] Including host 100 and storage system 102 Figure 1 The computing components can be implemented in one or more computer systems, for example Figure 13 The computer system 1302 shown is described in the general context of computer system executable instructions, such as program modules executed by the computer system. Typically, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The computer system / server 1302 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may reside in local and remote computer system storage media, including memory storage devices.

[0077] like Figure 13 As shown, the computer system / server 1302 is illustrated as a general-purpose computing device. Components of the computer system / server 1302 may include, but are not limited to, one or more processors or processing units 1304, system memory 1306, and a bus 1308 that couples various system components, including system memory 1306, to processor 1304. Bus 1308 represents one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using any of a variety of bus architectures. By way of example and not limitation, these architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

[0078] Computer system / server 1302 typically includes various computer system readable media. Such media can be any available media that can be accessed by computer system / server 1302, and it includes volatile and non-volatile media, removable and non-removable media.

[0079] System memory 1306 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1310 and / or cache memory 1312. Computer system / server 1302 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 1313 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and generally referred to as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and an optical disc drive may be provided for reading from or writing to a removable, non-volatile optical disc such as a CD-ROM, DVD-ROM, or other optical media. In such instances, each may be connected to bus 1308 via one or more data media interfaces. As will be further described below, memory 1306 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the invention.

[0080] By way of example and not limitation, a program / utility 1314 having at least one set of program modules 1316, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 1306. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Components of computer 1302 may be implemented as program modules 1316, which generally perform the functions and / or methods of embodiments of the invention as described herein. Figure 1 The system can be implemented in one or more computer systems 1302, wherein if they are implemented in multiple computer systems 1302, the computer systems can communicate via a network.

[0081] Computer system / server 1302 may also communicate with one or more external devices 1318, such as a keyboard, pointing device, display 1320, etc.; one or more devices that enable a user to interact with computer system / server 1302; and / or any device that enables computer system / server 1302 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication may occur via input / output (I / O) interface 1322. Furthermore, computer system / server 1302 may communicate with one or more networks, such as a local area network (LAN), a general area network (WAN), and / or a public network (e.g., the Internet), via network adapter 1324. As depicted, network adapter 1324 communicates with other components of computer system / server 1302 via bus 1308. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with computer system / server 1302. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0082] The terms “embodiment,” “multiple embodiments,” “this embodiment,” “these embodiments,” “one or more embodiments,” “some embodiments,” and “an embodiment” refer to “one or more (but not all) embodiments of the invention” unless otherwise expressly stated.

[0083] The terms “including,” “comprising,” “having,” and their variations mean “including but not limited to,” unless otherwise expressly stated.

[0084] Unless otherwise expressly stated, the list of items does not imply that any or all items are mutually exclusive.

[0085] The terms “a,” “an,” and “the” mean “one or more” unless otherwise explicitly stated.

[0086] Unless otherwise expressly stated, devices communicating with each other do not need to communicate continuously. Furthermore, devices communicating with each other may communicate directly or indirectly through one or more intermediaries.

[0087] The description of embodiments having several components that communicate with each other does not imply that all such components are required. Rather, various optional components are described to illustrate various possible embodiments of the invention.

[0088] When a single device or product is described herein, it will be apparent that more than one device / product (whether or not they collaborate) can be used in place of the single device / product. Similarly, when more than one device or product (whether or not they collaborate) is described herein, it will be readily understood that a single device / product can be used in place of more than one device or product, or that a different number of devices / products can be used in place of the number of devices or programs shown. The functionality and / or features of a device can alternatively be embodied by one or more other devices not explicitly described as having such functionality / features. Therefore, other embodiments of the invention do not necessarily need to include the device itself.

[0089] For purposes of illustration and description, the above description of various embodiments of the invention has been given. It is not exhaustive, nor is it intended to limit the invention to the precise forms disclosed. Many modifications and variations are possible in accordance with the above teachings. The scope of the invention is not defined by this detailed description but by the appended claims. The foregoing description, examples, and data provide a complete description of the manufacture and use of the components of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention is contained within the appended claims.

Claims

1. A computer program product for prefetching cache resources in response to write requests from a host for tracks cached in a cache, the tracks being stored in a storage device, the computer program product comprising program code executable to perform operations including: Before receiving an expected write for a track in the write set, release the cache resources held for that track in the write set; as well as After releasing the cache resources, cache resources are obtained for the tracks in the write set for the intended writes to the tracks in the write set.

2. The computer program product according to claim 1, wherein, The operation also includes: Maintain a cursor for the write set, the cursor indicating a track in the write set for which to begin prefetching cache resources, wherein obtaining cache resources includes: obtaining cache resources for sequential tracks in the write set from the track indicated by the cursor until the last track for which the cache resources are released.

3. The computer program product according to claim 1, wherein, Access to cached resources includes: Maintain a cursor for the write set, the cursor indicating a track in the write set for which to begin prefetching cache resources, wherein obtaining cache resources includes: obtaining cache resources for a fixed number of sequential tracks in the write set starting from the track following the cursor.

4. The computer program product according to claim 1, wherein, For write requests received from the host on the first channel, the cache resources are maintained for the write set, wherein the operation further includes: For cached resources in the write set that are unavailable on certain tracks, return a failure message for the first write request received on the first channel; and On the second channel, receive from the host a second write request to the track sent by the host in response to the failure of the first write request received on the first channel. Among them, obtaining cache resources includes: Estimate the number of writes the host may have sent on the second channel since the cache resource was released; Determine the start track, which is the estimated number of writes following the cursor pointing to the track in the write set where prefetching of cache resources begins after the cache resources are freed; and Obtain cache resources for sequential tracks in the write set, starting from the start track.

5. The computer program product according to claim 4, wherein, The estimated number of writes that the host may have performed includes: Determine the write time when the host completes the write request on the second channel; and The number of writes is estimated based on the pause time and the write time, during which write requests to the write set are paused, wherein the estimated number of writes is a function of the pause time divided by the write time.

6. The computer program product according to claim 1, wherein, For write requests received from the host on the first channel, the cache resources are maintained for the write set, wherein the operation further includes: For cached resources in the write set that are unavailable on certain tracks, return a failure message for the first write request received on the first channel; and On the second channel, the host receives a second write request for a track sent by the host in response to the failure of the first write request received on the first channel, wherein the second write request identifies the write set, and wherein cache resources for sequential tracks in the write set starting from the track following the track written by the second write request are obtained.

7. The computer program product according to claim 6, wherein, The operation also includes: In response to receiving a second write request identifying the write set on the second channel, a last retry track field for the write set is set to indicate the last track written by the second write request, wherein the cache resource is obtained from the track following the track indicated in the last retry track field.

8. The computer program product according to claim 6, wherein, The second write request also indicates whether the first write request will be retried on the first channel, wherein, in response to the second write request indicating that the first write request will not be retried, the cache resource is obtained from the track following the track written by the second write request, wherein the operation further includes: In response to the second write request indication, the first write request will be retried, and cache resources for sequential tracks in the write set starting from the track written by the second write request will be obtained.

9. The computer program product according to claim 1, wherein, In response to a pause in a write request to a volume including the write set on the first channel, the cache resource is released, wherein the cache resource is acquired in response to the end of the pause in the write request on the first channel.

10. A computer program product for sending a request to a storage controller that manages access to tracks in a storage device, the computer program product comprising program code that is executable to perform operations including: A first write request for a track in the write set is sent to the storage controller on the first channel, wherein, before receiving the write request for the track in the write set, the storage controller pre-allocates cache resources for the track in the write set; In response to the first write request, a failure is received from the storage controller; and In response to the failure of the first write request, a second write request is sent on the second channel for the track written by the first write request, wherein the second write request instructs the write set to enable the storage controller to obtain cache resources for the track in the write set that follows the track indicated in the second write request, wherein the obtained cache resources will be used for the expected write request to the track in the write set that will be sent on the first channel.

11. The computer program product according to claim 10, wherein, The operation also includes: The second write request indicates whether the first write request will be retried on the first channel, wherein, in response to the second write request indicating that the first write request will be retried on the second channel, the storage controller obtains cache resources from the track written by the first write request.

12. A system for prefetching cache resources in response to write requests from a host for tracks cached in a cache, the tracks being stored in a storage device, the system comprising: processor; Cache; as well as A computer-readable storage medium having computer-readable program code that, when executed by the processor, performs operations including: Before receiving an expected write for multiple tracks in the write set, release the cache resources held for the tracks in the write set; as well as After releasing the cache resources, cache resources are obtained for the tracks in the write set for the intended writes to the tracks in the write set.

13. The system according to claim 12, wherein, For write requests received from the host on the first channel, the cache resources are maintained for the write set, wherein the operation further includes: For cached resources in the write set that are unavailable on certain tracks, return a failure message for the first write request received on the first channel; and On the second channel, receive from the host a second write request to the track sent by the host in response to the failure of the first write request received on the first channel. Among them, obtaining cache resources includes: Estimate the number of writes the host may have sent on the second channel since the cache resource was released; Determine the start track, which is the estimated number of writes following the cursor pointing to the track in the write set where prefetching of cache resources begins after the cache resources are freed; and Obtain cache resources for sequential tracks in the write set, starting from the start track.

14. The system according to claim 12, wherein, For write requests received from the host on the first channel, the cache resources are maintained for the write set, wherein the operation further includes: For cached resources in the write set that are unavailable on certain tracks, return a failure message for the first write request received on the first channel; and On the second channel, the host receives a second write request for a track sent by the host in response to the failure of the first write request received on the first channel, wherein the second write request identifies the write set, and wherein cache resources for sequential tracks in the write set starting from the track following the track written by the second write request are obtained.

15. The system according to claim 14, wherein, The operation also includes: In response to receiving a second write request identifying the write set on the second channel, a last retry track field for the write set is set to indicate the last track written by the second write request, wherein the cache resource is obtained from the track following the track indicated in the last retry track field.

16. The system according to claim 14, wherein, The second write request also indicates whether the first write request will be retried on the first channel, wherein, in response to the second write request indicating that the first write request will not be retried, the cache resource is obtained from the track following the track written by the second write request, wherein the operation further includes: In response to the second write request indication, the first write request will be retried, and cache resources for sequential tracks in the write set starting from the track written by the second write request will be obtained.

17. The system according to claim 12, wherein, In response to a pause in a write request to a volume including the write set on the first channel, the cache resource is released, wherein the cache resource is acquired in response to the end of the pause in the write request on the first channel.

18. A system for sending requests to a storage controller that manages access to tracks in a storage device, comprising: processor; as well as A computer-readable storage medium containing computer-readable program code executable to perform operations including: A first write request for a track in the write set is sent to the storage controller on the first channel, wherein, before receiving the write request for the track in the write set, the storage controller pre-allocates cache resources for the track in the write set; In response to the first write request, a failure is received from the storage controller; and In response to the failure of the first write request, a second write request is sent on the second channel for the track written by the first write request, wherein the second write request instructs the write set to enable the storage controller to obtain cache resources for the track in the write set that follows the track indicated in the second write request, wherein the obtained cache resources will be used for the expected write request to the track in the write set that will be sent on the first channel.

19. The system according to claim 18, wherein, The operation also includes: The second write request indicates whether the first write request will be retried on the first channel, wherein, in response to the second write request indicating that the first write request will be retried on the second channel, the storage controller obtains cache resources from the track written by the first write request.

20. A method for prefetching cache resources in response to a write request from a host for a track cached in a cache, the track being stored in a storage device, the method comprising: Before receiving an expected write for multiple tracks in the write set, release the cache resources held for the tracks in the write set; as well as After releasing the cache resources, cache resources are obtained for the tracks in the write set for the intended writes to the tracks in the write set.

21. The method according to claim 20, wherein, For write requests received from the host on the first channel, the cache resource is maintained for the write set, and the method further includes: For cached resources in the write set that are unavailable on certain tracks, return a failure message for the first write request received on the first channel; and On the second channel, receive from the host a second write request to the track sent by the host in response to the failure of the first write request received on the first channel. Among them, obtaining cache resources includes: Estimate the number of writes the host may have sent on the second channel since the cache resource was released; Determine the start track, which is the estimated number of writes following the cursor pointing to the track in the write set where prefetching of cache resources begins after the cache resources are freed; and Obtain cache resources for sequential tracks in the write set, starting from the start track.

22. The method according to claim 20, wherein, For write requests received from the host on the first channel, the cache resource is maintained for the write set, and the method further includes: For cached resources in the write set that are unavailable on certain tracks, return a failure message for the first write request received on the first channel; and On the second channel, the host receives a second write request for a track sent by the host in response to the failure of the first write request received on the first channel, wherein the second write request identifies the write set, and wherein cache resources for sequential tracks in the write set starting from the track following the track written by the second write request are obtained.

23. The method of claim 22, further comprising: In response to receiving a second write request identifying the write set on the second channel, a last retry track field for the write set is set to indicate the last track written by the second write request, wherein the cache resource is obtained from the track following the track indicated in the last retry track field.

24. The method according to claim 22, wherein, The second write request also indicates whether the first write request will be retried on the first channel, wherein, in response to the second write request indicating that the first write request will not be retried, the cache resource is obtained from the track following the track written by the second write request, and the method further includes: In response to the second write request indication, the first write request will be retried, and cache resources for sequential tracks in the write set starting from the track written by the second write request will be obtained.

25. The method according to claim 20, wherein, In response to a pause in a write request to a volume including the write set on the first channel, the cache resource is released, wherein the cache resource is acquired in response to the end of the pause in the write request on the first channel.

Images