Retrieving cache resources for anticipated write operations on tracks in a write set after the cache resources for the tracks in the write set have been released.

Abstract

Computer program product for pre-retrieving cache resources for a write request (400) from a host (100) on tracks (302) which are temporarily stored in a cache (140), wherein the tracks (302) are stored in a memory (104), wherein the computer program product comprises a computer-readable storage medium which contains computer-readable program code embodied therein, which is executable to perform operations, wherein the operations comprise: Release (504) cache resources held for tracks (302) in a write set (200) before expected write operations for the tracks (302) in the write set (200) are received; and Retrieving (602) cache resources for the tracks (302) in the write set (200), following the release of the cache resources to be used for the expected write operations to the tracks (302) in the write set (200).

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention

[0001] The present invention relates to a computer program product, a system, and a method for retrieving cache resources for expected write operations to tracks in a write set after the cache resources for the tracks in the write set have been released. 2. Description of related technology

[0002] In a storage environment, a host system may first transmit a write / read request to an attached storage system over a fast channel, such as a bus interface or a Peripheral Component Interconnect Express (PCIe) interface. For a write / read request over the fast channel that should be completed within a threshold time period, the host system keeps the application thread for the write / read request in a spin loop, waiting for the request to complete. This saves processor time associated with a context switch, which disables the thread and re-enables the thread in response to an interrupt when a response to the write / read request is received.If the data for the write / read request sent over the fast channel is not in the cache, the storage system can abort the write / read request, and the host system can transmit the same write / read request over a storage area network via a host adapter, which is slower than processing the I / O request over the bus, such as the PCIe interface. When transmitting the write / read request over the second channel, the host system must perform a context switch from the task servicing the write / read request to another task while waiting for the write / read request to complete.A context switch is costly because the processor executing the task must flush the contents of all registers and L1 and L2 caches for the new task, and then, upon completing the new task, re-enable the context-switched task and return state data to the registers and L1 and L2 caches for the context-switched task while waiting for the write / read request to complete.

[0003] Certain read / write operations must complete within a threshold time period or fail. To process a read or write request, the storage system must allocate cache resources, including resources and segments in cache memory, and access track metadata to process the read or write request. Track metadata provides information about the data format and record structure in the track, which is required to perform read and write operations on the track. However, allocating cache resources, including accessing metadata, from memory accounts for a significant portion of the latency when processing read / write requests.

[0004] In the prior art, US 2019 / 0 073 310 A1 discloses a computer program product, a system, and a method for managing access requests from a host to tracks in memory. US 2006 / 0 190 688 A1 discloses a data processing system with prefetching means. US 2010 / 0 232 057 A1 discloses techniques for storing shingle blocks in a cache memory using a data storage device.

[0005] There is a need in the art for improved techniques to pre-cache cache resources for host write requests on the fast channel so that the cache resources are available for lanes when the write requests to the lanes are received on the fast channel. SUMMARY

[0006] The invention is described by the features of the independent claims. Embodiments are specified in the dependent claims.

[0007] Provided are a computer program product, a system, and a method for prefetching cache resources for a write request from a host to tracks in memory stored in a cache. Cache resources held for a plurality of tracks in a write set are released before expected write operations for the tracks in the write set are received. Cache resources for tracks in the write set are retrieved following the release of the cache resources to be used for expected write requests to the tracks in the write set.

[0008] In the above embodiment, when cache resources for tracks in a write set are released, those resources become available for other requests, which is optimal when the expected write operations to the tracks in the write set cannot proceed, for example, when access to the write set is shut down due to an event such as a volume being unselectable due to a long-lived condition or unsupported copy services or other processes.Following the release of cache resources, reclaiming cache resources for the lanes for which they were released increases the probability that write requests sent by the host to the write set will complete within a required threshold time, which is particularly important for performance when a host thread on the write request task is idle for the write request.

[0009] In another embodiment, the cache resources for the write set are held for write requests received on a first channel from the host. A miss is returned on a first write request received on the first channel for a track in the write set for which no cache resources are available. A second write request to a track from the host is received on a second channel, which the host sends in response to receiving the miss on the first write request on the first channel.Fetching the cache resources includes estimating a number of write operations that the host may have sent on the second channel since releasing the cache resources, setting a starting track, which is the estimated number of write operations following a cursor pointing to a track in the write set at which to begin prefetching cache resources after the cache resources are released, and fetching cache resources for sequential tracks in the write set starting from the starting track.

[0010] In the above embodiment, a number of write operations that the host may have performed on the second channel is estimated, so that prefetching of those tracks estimated to have been written on the second channel is skipped, since cache resources are no longer required for those tracks written on the second channel. In this way, prefetching is optimized by starting prefetching from a first track in the write set after quiescing, which is unlikely to have been written by a write operation sent on the second channel.

[0011] In another embodiment, the cache resources for the write set are held for write requests received on a first channel from the host. A miss is returned on a first write request received on the first channel for a track in the write set for which no cache resources are available. A second write request to a track is received on a second channel from the host, which the host sends in response to receiving the miss on the first write request on the first channel. The second write request identifies the write set, with cache resources for sequential tracks in the write set being retrieved starting at a track following the track written by the second write request.

[0012] In the above embodiment, fetching cache resources for a track following the track written by the second write request on the second channel avoids prefetching for tracks that have already been written on the second channel because the host is unlikely to retry writing to a track on the first channel that has been successfully written on the second channel.

[0013] In another embodiment, in response to receiving the second write request on the second channel identifying the write set, a last track repeated field is set for the write set to indicate a last track written by the second write request. Cache resources are retrieved starting from a track following the track specified in the last track repeated field.

[0014] In the above embodiment, cache resources are prefetched following the last track written on the second channel, since the host may not attempt to reaccess a track on the first channel that has already been accessed on the second channel. Thus, detecting the last written track allows cache resources to be prefetched following the last written track, so that cache resources are only fetched for tracks likely to be written on the first channel, avoiding fetching cache resources for tracks that are not likely to be written.

[0015] In another embodiment, the second write request further indicates whether the first write request will be retried on the first channel. Cache resources are retrieved starting from the track following a track described by the second write request in response to the second write request indicating that the first write request will not be retried. Cache resources are retrieved for sequential tracks in the write set starting from the track described by the second write request in response to the second write request indicating that the first write request will be retried.

[0016] In the above embodiment, the host provides an indication of whether a failed write request retried on the second channel will also be retried on the first channel. This indication enables optimization by prefetching cache resources starting from the track written on the second channel, since the host also retries the write operation on the first channel, so that the cache resources are available for the write request on the first channel so that the write operation on the first channel can be completed.

[0017] Provided are a computer program product, a system, and a method for sending requests to a memory controller that manages access to tracks in a memory. A first write request to a track in a write set is sent to the memory controller on a first channel. Cache resources for tracks in the write set are pre-allocated by the memory controller before write requests to the tracks in the write set are received. A fault is received by the memory controller in response to the first write request. A second write request, for the track described by the first write request, is sent on a second channel in response to the fault of the first write request.The second write request specifies the write set to cause the memory controller to retrieve cache resources for tracks in the write set that follow the track specified in the second write request. The retrieved cache resources are used for expected write requests to the tracks in the write set sent on the first channel.

[0018] In another embodiment, an indication is made in the second write request as to whether the first write request will be retried on the first channel. The memory controller is caused to retrieve cache resources starting from the lane described by the first write request in response to the second write request indicating that the first write request will be retried on the second channel.

[0019] In the above embodiments, the host may indicate to the memory controller whether the host will retry write requests on the first channel to allow the memory controller to match a prefetch to a sequential track in the write set that follows the last written track if the write requests are not retried. If the host retries write requests written on the second channel on the first channel, this indication of retry in the write request on the second channel further ensures that the cache resources for the tracks written by the second channel write request are retrieved for use during the first channel write requests.Furthermore, if the write requests are replayed on the second channel, the last-track-replayed field is not set to indicate the last track written by the write request, so that cache resources are fetched for those tracks that are replayed on the second channel. This optimizes prefetch operations by adjusting the prefetch as needed to avoid prefetching cache resources for written tracks that are not rewritten by a write request on the first channel, so that cache resources do not need to be fetched when they are not needed for replay write operations on the first channel. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates one embodiment of a storage environment. Fig. 2 illustrates one embodiment of writing sentence information for a created writing sentence. Fig. 3 illustrates one embodiment of a track access list entry in a track access list. Fig. 4 illustrates one embodiment of a second channel write request sent on the second channel to retry a write request that failed on a first channel. Fig. 5 illustrates one embodiment of operations to process a write set quiesce. Fig. 6 illustrates one embodiment of operations to process an end of write set quiescing. The Fig. 7, Fig. 8, Fig. 9 and Fig. 12 illustrate embodiments of operations to retrieve cache resources for expected write requests on the first channel when the write set quiesces ends. Fig. 10 illustrates one embodiment of operations performed by a host system to generate a second channel write request to a storage system to retry a failed write request sent on the first channel to write the tracks. Fig. 11 illustrates one embodiment of operations performed by the storage system to process a second channel write request from the host. Fig. 13 illustrates an embodiment of a computer architecture used with described embodiments. DETAILED DESCRIPTION

[0020] An access to a write set may be quiesced if an event occurs that prevents write access to the tracks for an extended period of time to allow other processes to access the tracks held for the write set, such as a disk ineligibility due to a long-running condition or unsupported copy services or other processes. Quiescing access to tracks in a write set causes the cache resources for the tracks in the write operation to be deallocated. Deallocating cache resources causes first-channel write requests to fail to retry writing to the tracks in the quiesced write set if there are no pre-allocated cache resources for those write requests when the requests are received.

[0021] By accessing cache resources prior to write requests on the first channel after the event that caused the cache resources to be released, such as a write set quiescing, latency in processing the access request is minimized. By accessing cache resources prior to the access request, described embodiments further increase the likelihood that write requests sent by the host on a first fast channel will complete within a required threshold time period for processing access requests on the first channel that require fast processing. This keeps the time the host thread on the write request task is idle for the write request sent on the bus interface within an acceptable time threshold.However, if the cache resources for a requested target lane were not allocated prior to the request, having been freed as a result of another operation being retired, the write request resubmitted on the first channel may fail again because the write request is unlikely to complete within the threshold time period, given that the cache resources must be allocated. A write request failure on the first channel causes the host to retry the write request on the second channel. Processing the write request on the second channel allocates the required cache resources while processing the access request.

[0022] Described embodiments provide improvements to computer technology for prefetching cache resources by refetching cache resources for tracks in a write set that have been deallocated due to a quiesce or other process. Described embodiments use techniques to estimate where write requests on the first channel will begin when the host retries the failed first channel write request on a second channel. In this way, the storage system optimizes prefetching cache resources by refetching cache resources for tracks in a write set that are likely to be written to by subsequent write requests on the first channel, and avoids refetching cache resources for tracks in the write set that will not be accessed again by write requests on the first channel.

[0023] Fig. 1 illustrates one embodiment of a storage environment 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 volumes configured in storage units 104 in a disk enclosure 106. The host 100 includes a processor complex 108 of one or more processor units and a main memory 110 including an operating system 111 executed by the processor complex 108. The host operating system 111 generates read and write requests to tracks configured in the storage units 104. The host 100 includes hardware to transmit read and write requests on two different channels.A "first channel" may include a bus interface such as a Peripheral Component Interconnect Express (PCIe) that includes a bus 112, a bus switch 114 to connect one or more devices on the bus 112, including the processor complex 108, a main memory system 110, and a bus host adapter 116 to extend the bus interface to the memory system 102 via an external bus interface cable 118. Additional bus interface technology may be used to extend the bus interface, including PCIe extension cables or components, such as a distributed PCIe switch to enable PCIe over Ethernet, such as with ExpEther technology.

[0024] A "second channel" to connect host 100 and storage system 102 may utilize a network host adapter 120 connected to bus 112, which is connected to a separate network 122 over which host 100 and storage system 102 additionally exchange data. The first channel through the bus interface may have a faster access channel than the second channel, which uses the interface of network 122 through network host adapter 120.

[0025] The storage system 102 includes a bus interface having a bus 124a, 124b, a bus switch 126 for connecting to endpoint devices on the bus 124a, 124b, and a bus host adapter 128 for connecting to the external bus interface cable 118 to enable transmission across the bus interface to the host 100 via the first channel. The storage system 102 includes an input / output panel 130 having the bus host adapter 128, one or more device adapters 132 for connecting to the storage devices 104, and one or more network host adapters 134 for connecting to the network 122 and host systems.

[0026] The storage system 102 includes a processor complex 136 of one or more processor units and a main memory 138 having a cache 140 for temporarily storing traces accessed by the connected hosts 100. The main memory 138 includes a write access manager 142 for managing write requests to the cache 140 and a memory manager 144. The memory manager 144 manages access requests from processes in the hosts 100 and the storage system 102 for traces in the memory 104. The units 136, 138, 128, 132, and 134 are connected via the bus interface implemented in the bus lanes 124a, 124b and the bus switch 126.

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

[0028] A track may comprise any unit of data configured in memory 104, such as a track, a logical block address (LBA), etc., that is part of a larger grouping of tracks, such as a volume, a logical unit, etc.

[0029] The write access manager 142 maintains cache management information 146 in the main memory 138 to manage read (unmodified) and write (modified) tracks in the cache 140. The cache management information 146 may include a track index 148 that provides an index from tracks in the cache 140 to cache control blocks in a control block directory 150; and a least recently used (LRU) list 152 for tracks in the cache 140. The control block directory 150 includes the cache control blocks, with one cache control block for each track in the cache 140 that provides metadata on the track in the cache 140. The track index 148 associates tracks with the cache control blocks, which provide information about the tracks in the cache 140.After determining that the cache LRU list 152 is full or has reached a threshold, tracks are demoted from the LRU list 152 to make room for additional tracks to be stored from the memory 104 into the cache 140.

[0030] The cache management information 146 may further include write set information 200 of a write set of tracks created by the host 100 for tracks to be written on the first channel. The write access manager 140 may prefetch cache resources for tracks in the write set before receiving write transactions. The host 100 may create multiple write sets for multiple ranges of tracks, for which track resources are allocated in anticipation of multiple data streams from sequential write transactions to the different ranges of tracks.

[0031] The host operating system 111 may create a write set 200 for a range of tracks 204 before sending write requests for sequential write transactions so that the write access manager 142 pre-allocates cache resources for the write set in anticipation of the sequential write transactions that are likely to be directed soon to the tracks specified in the write set. These pre-allocated cache resources reduce the latency of processing the sequential write requests when they are eventually received. Furthermore, by allocating cache resources for a limited (fixed) number of a first subset of tracks within the write set, cache resources are retained only for those tracks most likely to be written as part of a sequential write data stream.Furthermore, the number of tracks for which cache resources are held is limited so that these cache resources can be available for access by other processes in the host operating system 111 or other attached hosts 100.

[0032] A cache resource held and accessed for tracks in the range of tracks 302 may include a segment in cache 140 to be used for the track to be written, a segment in non-volatile memory if a copy of write tracks is to be stored in non-volatile memory in the same or a different cluster, track metadata for the track, and other types of cache resources needed to process a write transaction to the track.

[0033] In certain embodiments, there may be multiple hosts 100 connected to the storage system 102 via the first and second channels to access lanes in the storage devices 104. In this case, the storage system 102 would have at least one bus host adapter 128 for connecting to the bus interface 118 of each connected host 100 and one or more network host adapters 134 for connecting to the network host adapters 120 on the hosts 100.

[0034] In a single embodiment, bus interfaces 112, 114, 116, 118, 124a, 124b, 126, and 128 may comprise Peripheral Component Interconnect Express (PCIe) bus interface technology. In alternative embodiments, bus interfaces 112, 114, 116, 118, 124a, 124b, 126, and 128 may use a suitable bus interface technology other than PCIe. Bus host adapters 116 and 128 may comprise PCIe host adapters that provide the interface for connecting to PCIe cable 118. Network 122 may be a storage area network (SAN), a local area network (LAN), a wide area network (WAN), Fibre Connection (FICON ® ), the Internet, an intranet, etc., and the network host adapters 120, 134 provide the network 122 connections between the hosts 100 and the storage system 102. (FICON is a worldwide registered trademark of International Business Machines Corporation).

[0035] The storage system 102 may be a storage system, also referred to as a control unit and storage controller, such as the DS8000 storage system ® and the DS8880 storage system from International Business Machines Corporation (IBM ® ) or storage controllers and storage systems from other manufacturers. (IBM and DS8000 are registered trademarks of International Business Machines Corporation worldwide.) The host operating system 111 may be an operating system such as the Z Systems Operating System (Z / OS ® ) of International Business Machines Corporation ("IBM") or other operating systems known in the art. (Z / OS is a registered trademark of IBM worldwide.)

[0036] The storage devices 104 in the disk enclosure 106 may include various types or classes of storage devices, such as magnetic hard disk drives, a solid-state storage device (SSD) comprised of solid-state electronics, an EEPROM (Electrically Erasable Programmable Read-Only Memory), a flash memory, a flash disk, a random access memory (RAM) drive, a storage-class memory (SCM), etc., a phase change memory (PCM), a resistive random access memory (RRAM), a spin-transfer torque memory (STT-RAM), a conductive bridging RAM (CBRAM), a magnetic hard disk drive, an optical disk, a tape, etc.Disks in a storage area may further be configured from an array of devices such as a Just a Bunch of Disks (JBOD), a Direct Access Storage Device (DASD), a Redundant Array of Independent Disks (RAID) array, a virtualization device, etc. Furthermore, the storage devices 104 in the disk enclosure 106 may include heterogeneous storage devices from different manufacturers, as well as different types of storage devices, such as a first type of storage device, e.g., hard disk drives, having a slower data transfer rate than a second type of storage device, e.g., SSDs.

[0037] Fig. 2 illustrates an embodiment of an instance of write set information 200 ifor a created write set to receive write requests on the first channel, including a write set identifier (ID) 202 that provides a unique identifier of a write set; a range of tracks 204 to which sequential write transactions are expected on the first channel and for which cache resources should be accessed prior to the sequential write transactions; a track access list 300 that indicates, for each track in the range of tracks 204, whether the cache resources for the track are held and whether the track has been accessed since receiving the created write set 200 i described; a prefetch cursor 206 indicating a lane in the range of lanes 302 from which allocation of cache resources for sequential write transactions in the write set 202 should begin; a last lane released field 208 used when the embodiment of Fig. 7, and which indicates a last track for which cache resources are released; and a method used in the embodiments of Fig. 10, Fig. 11 and Fig. 12 used last track repeated field 210, which has a track in the range of tracks 204, which is represented by a signal on the second channel (components 120, 122, 134 in Fig. 1) sent write request is described.

[0038] In certain embodiments, during regular processing, the prefetch cursor 206 may be set to point to the lane that the write access manager 142 expects to be written to by the host 100 (if actively writing) or to be written to next (if not actively writing). The prefetch cursor 206 points to the location where the write access manager 142 places the host 100 in its processing.

[0039] Fig. 3 illustrates one embodiment of a track access list entry 300 i in the track access list 300, which indicates a track identifier (ID) 302; a cache resource held flag 304, which indicates whether cache resources are held for the track 302; and a track written flag 306, which indicates whether the track 302 has been written since the creation of the write set 202.

[0040] Fig. 4 illustrates one embodiment of a second channel write request 400 received from host 100 on the second channel, including: a write operation code 402; a define scope range 404 of a subset of tracks in a write set 408 to which the following one or more sequential write transactions 406 are directed; and a retry on first channel flag 410 indicating whether the write transactions 406 in the second channel write request 400 are subsequently retried on the faster first channel.

[0041] Fig. 5 illustrates one embodiment of operations performed by the write access manager 142 to process a write set quiescing. The quiescing may be caused by the volume comprising the write set becoming ineligible, there being no input / output (I / O) activity for an extended period of time with respect to the tracks associated with the write set, or there being copy operations directed to a volume comprising the write set, such as replication, mirroring, etc., or other causes for the write set quiescing. After processing (at block 500) a write set quiescing 200 i the write access manager 142 (at block 502) provides for the track access list 300 for the write set 200 i Tracks in the write set that have allocated cache resources as specified in field 304 of the track access list entries 300 iin the track access list 300 for the write set 200 i is specified. The cache resources are released (at block 504) with respect to the detected tracks. The write access manager 142 updates (at block 506) the track access list entries 300 i for all tracks for which cache resources have been released to indicate that no cache resources are held, 304. For the embodiment of Fig. 7, a last track released field 208 is set (at block 508) to a last track in the write set for which cache resources have been released. For the embodiment of Fig. 11 and Fig. 12, a last track repeated field 210 is set to zero (at block 510), indicating that no write operation to the track has occurred since the end of the quiesce.

[0042] In the embodiment of Fig. 5, after processing a retirement of tracks in a write set, the cache resources for those tracks in the write set are released to make them available for other cache operations. Cache resources must be fetched again from the prefetch cursor 206 if write operations on the first channel to the write set are to resume.

[0043] Fig. 6 illustrates one embodiment of operations performed by the write access manager 142 to process an end of quiescing of the write set. After processing (at block 600) an end of quiescing, the write access manager 142 retrieves (at block 602) cache resources for sequential tracks from the prefetch cursor 206 that are available for expected write requests to the tracks in the write set according to one of the embodiments of the Fig. 7, Fig. 8, Fig. 9, Fig. 12 are to be used. The prefetch cursor 206 may have been set prior to quiescing during normal track prefetch operations in anticipation of write transfers from the host 100. The write access manager 142 indicates (at block 604) in the track access list 300 all tracks for which cache resources are being accessed / held by setting field 304 ( Fig. 3) to indicate that cache resources are being held for track 302. The prefetch cursor 206 is set (at block 606) to point to a starting point of tracks for which cache resources have been fetched to enable prefetching of cache resources that have been freed.

[0044] In the embodiment of Fig. 6, after the write set quiesces ends, cache resources are fetched for tracks in the write operation for which further write operations are expected to be received on the first channel. Prefetching begins from the prefetch cursor 206, which was set before quiescing during normal track prefetching. Thus, the prefetch cursor points to the beginning of the tracks for which cache resources were released. Fetching cache resources before receiving write requests on the first channel allows write requests to proceed, as the transaction can be processed very quickly with acceptable latency using the preallocated cache resources.

[0045] If cache resources have not been allocated to enable low-latency processing of the write request, the write request fails because the transaction is unlikely to complete within a fast time threshold. This determination is made to avoid host delays in processing other tasks while the host processor on the thread servicing the write request is idle while waiting for the write request to complete. If cache resources have already been pre-allocated, there is a high probability that the write operation on the first channel can complete within the latency threshold necessary to prevent the host processor from holding the thread for too long, causing other I / O requests to be queued and delayed.Returning a miss when the cache resources have not been pre-allocated will cause the host thread waiting for the write request task to be disabled, and the host processor may perform a context switch to process other tasks, and the write request will then be retried on the second network channel during the context switch.

[0046] Furthermore, in described embodiments, the cache resources held for the target track may be released once a write request is completed, and the cache resources for a next track in the range of tracks may then be accessed.

[0047] Fig. Figure 7 illustrates one embodiment of operations performed by the write access manager 142 for the prefetch operation at block 602 in Fig. 6. After initiating (at block 700) the prefetch operation at block 602 in Fig. 6, to retrieve cache resources for write requests of the first channel, the write access manager 142 retrieves (at block 702) cache resources for tracks in the write set 200 i from the prefetch cursor 206 to the last released track 208.

[0048] In the embodiment of Fig. 7, the write access manager 142 retrieves resources for all tracks for which at block 504 ( Fig. 5) Cache resources have been released so that write operations for the write set on the fast first channel can continue after the quiescing ends.

[0049] Fig. Figure 8 illustrates one embodiment of operations performed by the write access manager 142 to perform the prefetch operation at block 602 in Fig. 6. After initiating (at block 800) the prefetch operation at block 602 in Fig. 6, to retrieve cache resources for write requests of the first channel, the write access manager 142 retrieves (at block 802) cache resources for a fixed number of sequential tracks in the write set 200 i that follow the prefetch cursor 206.

[0050] In the embodiment of Fig. 8, the write access manager 142 fetches resources for a fixed number of tracks starting from a track following the track pointed to by the prefetch cursor, assuming that the host 100 would have retried a write request on the second channel for a first track of the tracks for which cache resources were deallocated, indicated by the prefetch cursor 206. By skipping the track indicated by the prefetch cursor 206 or the track following the first track in the write set for which cache resources were deallocated, the write access manager 142 avoids prefetching cache resources for a track that would likely have been written to by a write request sent on the second channel after the write request on the first channel failed.

[0051] Fig. 9 illustrates one embodiment of operations performed by the write access manager 142 for the prefetch operation at block 602 in Fig. 6 by estimating a number of write operations that the host 100 may have sent on the second channel since the cache resources were released as part of the write set retirement. After initiating (at block 900) the prefetch operation at block 602 in Fig. 6, to retrieve cache resources for first channel write requests, the write access manager 142 sets (at block 902) a second channel write time for the host to complete a write request on the second channel, which may be a preset value or an average time to complete recently issued second channel write requests. The write access manager 142 estimates (at block 904) a number of write operations performed by the host on the second channel during the quiesce time as a function of the quiesce time and the second channel write time, e.g., the quiesce time divided by the second channel write time. A starting track is set (at block 906) as a number of tracks having the estimated number of write operations following the prefetch cursor 206.The prefetch cursor 206 is then set to the starting lane (at block 908). The write access manager 142 retrieves cache resources for a fixed number of lanes from the prefetch cursor, including the lane at the prefetch cursor 206 (at block 910).

[0052] In the embodiment of Fig. 9, the write access manager 142 estimates a number of write operations that the host may have performed on the second channel in order to skip fetching cache resources for those tracks that are estimated to have already been written on the second channel during the quiescing, since the cache resources for these tracks written on the second channel are no longer needed. In this way, the embodiment of Fig. 9 performs a prefetch by starting a prefetch after quiescing from a first track in the write set that is unlikely to have been written to by a write operation 400 sent on the second channel.

[0053] The Fig. 10, Fig. 11 and Fig. 12 illustrate an embodiment in which the host 100 retries write requests that failed on the first channel on the second channel by encoding the write request on the second channel with information about where the write access manager 142 can begin prefetching, the information including a write set ID 408 and a retry on first channel flag 410.

[0054] Fig. 10 illustrates one embodiment of operations performed by the operating system 111 of the host 100 upon receipt of an error from the storage system 102 on a write request to (a) track(s) in a write set 200 sent on the first channel. i After receiving (at block 1000) the error, the host 100 generates (at block 1002) a write request 400 on the second channel for the track(s) written by the failed write request on the first channel. The write set 200 iThe track(s) to be rewritten on the second channel is specified (at block 1004) in the write set field 408. If the host 100 is configured (at block 1006) to retry the write request 400 on the first channel, the retry on first channel flag 410 is set (at block 1008) to indicate that the write request 400 will be retry on the first channel. If the write request 400 is not to be retry on the first channel (at block 1006), the retry on first channel flag 410 is set (at block 1010) to indicate that the write request 400 will not be retry on the first channel. After the flag 410 is set at block 1008 or 1010, the write request 400 is sent (at block 1012) to the storage system 102 on the second channel.

[0055] Fig. 11 illustrates one embodiment of operations performed by the write access manager 142 of the storage system 102 to process a write request 400 from the host 100 on the second channel during a quiescing of write operations to a write set. Upon receiving (at block 1100) a write request on the second channel, the write access manager 142 determines (at block 1102) whether the write request 400 specifies a write set 408 established for write requests on the first channel. If no write set 408 is specified (at block 1102), the second write request is processed (at block 1104).If a write set 408 is specified (at block 1102) and the retry on first channel flag 410 indicates (at block 1106) that the write request that failed on the first channel and resulted in the received write request 400 will not be retried on the first channel, the last track retried field 210 for the write set 408 is set (at block 1108) to a track following the track (or last track) described by the write request 400. If the repeat on first channel flag 410 indicates (at block 1106) that the write request will be repeated on the first channel or after the last track repeated field 210 is set (at block 1108), the second write request 400 is processed (at block 1104) to write the tracks in the write set.

[0056] Fig. 12 illustrates one embodiment of operations performed by the write access manager 142 to allocate cache resources for tracks in a write set 200 i to be retrieved in advance after the cessation of access to the write set 200 i

[0057] ends. If (at block 1200) after initiating prefetch operations, the last track repeated field 210 indicates a track, the prefetch cursor 206 is set to the track indicated in the last track repeated field 210. If (at block 1202) the last track repeated field 210 does not indicate a track, or after setting (at block 1204) the prefetch cursor 206, the write access manager 142 retrieves cache resources for a fixed number of sequential tracks in the write set starting from the prefetch cursor 206.

[0058] In the design of the Fig. 10, Fig. 11 and Fig. 12, if the write request 400 is also replayed on the first channel, the write access manager 142 must also prefetch cache resources for the track(s) described by the write request 400 to successfully process the first channel write request. To ensure that the cache resources for the tracks described by the second channel write request 400 are preplayed, the last track replayed field 210 is not set to indicate the last track described by the write request 400, so that cache resources are prefetched starting from the current position of the prefetch cursor 206. If the write request is not replayed on the first channel, the write access manager 142 does not need to prefetch cache resources for the tracks described by the second channel write request 400.In this case, to skip prefetching the track(s) just written, the last track repeated field 210 is set to a track following the last track written by the write request 400, so that after quiescing, the write access manager 142 begins prefetching from tracks in the write set following the tracks written by the second channel write request 400.

[0059] In the design of the Fig. 10, Fig. 11 and Fig. 12, the host 100 may indicate to the write access manager 142 whether the host will retry the write requests on the first channel to allow the write access manager 142 to adjust the prefetch cursor 206 to a sequential track in the write set that follows the last written track if the write requests are not retried. This optimizes prefetch operations by adjusting the prefetch cursor 206, if necessary, to avoid prefetching cache resources for written tracks that are not accessed by a write request on the first channel, thus eliminating the need to fetch cache resources.

[0060] In a single embodiment, where the second channel is a Fibre Connection (FICON ®-)connection, which is the proprietary name of the International Business Machines Corporation (IBM) for the ANSI FC-SB-3 Single-Byte Command Code Sets-3 Mapping Protocol for Fibre Channel (FC), the first channel being the IBM zHyperLink and the host operating system 111 Z / OS ® , the host 100 can retry a failed zHyperLink write operation (first channel) over the FICON interface (second channel) by adding new fields, such as the retry write operation on the first channel flag 410 and a write set ID 408, to associate the FICON IO with the write set 408. This additional information enables the write access manager 142 to retry the last track retried field 210 in the write set information 200. ifor the respective lane. When the write set quiescing completes, the host 100 begins re-fetching lanes after the last re-fetched lane 210. The host 100 may further have software hints to notify the storage system 102 that the host will retry the write operation on the zHyperLink (first channel) to control where the storage system 102 aligns for pre-fetching.

[0061] The present invention may be a system, a method, and / or a computer program product. The 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 present invention.

[0062] The computer-readable storage medium may be any physical device capable of retaining and storing instructions for use by an instruction-executing system. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a removable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), removable compact disk read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as carrying transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light traveling through fiber optic cables), or electrical signals conveyed through a wire.

[0063] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.

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

[0065] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer-readable program instructions.

[0066] 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 device to produce a machine such that the instructions, executed by the processor of the computer or other programmable data processing device, produce a means for implementing the functions / steps defined in the flowchart block(s) and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored thereon comprises an article of manufacture, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams.

[0067] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-executable process such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / steps defined in the block(s) of flowcharts and / or block diagrams.

[0068] The flowcharts and block diagrams in the figures 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 the flowchart or block diagrams may represent a module, segment, or section of instructions comprising one or more executable instructions for performing the specified logical function(s). In some alternative implementations, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown in sequence may actually execute substantially concurrently, or the blocks may sometimes execute in reverse order depending on the corresponding functionality.It is further understood that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or steps, or by combinations of special purpose hardware and computer instructions.

[0069] The computing components of Fig. 1, including the host 100 and the storage system 102, may be implemented in one or more computer systems, such as the one shown in Fig. 13. The computer system / server 1302 may be described in the general context of computer system-executable instructions, such as program modules executed by a computer system. In general, program modules may include routines, programs, objects, components, logic, data structures, and so on, that perform particular tasks or execute particular abstract data types. The computer system / server 1302 may be put into practice in distributed cloud computing environments in which tasks are performed by remote processing units connected by a transmission network. In a distributed cloud computing environment, program modules may be located in both local and remote storage media of a computer system, including main memory units.

[0070] As in Fig. 13, the computer system / server 1302 is shown in the form of a general-purpose data processing unit. Components of the computer system / server 1302 may include, but are not limited to, one or more processors or processing units 1304, a system memory 1306, and a bus 1308 that connects various system components, including the system memory 1306, to the processor 1304. The bus 1308 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnects (PCI) bus.

[0071] The computer system / server 1302 typically includes a variety of computer system-readable storage media. These storage media may be any available storage media accessible by the computer system / server 1302, including both volatile and non-volatile storage media, as well as removable and non-removable storage media.

[0072] The system memory 1306 may include computer system-readable media in the form of volatile memory, such as a random access memory (RAM) 1310 and / or a cache 1312. The computer system / server 1302 may further include other removable / non-removable and volatile / non-volatile storage media of a computer system. By way of example only, the storage system 1313 may be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and commonly referred to as a "hard disk drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g.,a "floppy disk") and an optical disk drive for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In these cases, each drive may be connected to bus 1308 through one or more media interfaces. As further illustrated and 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.

[0073] A program / utility 1314 having a set (at least one) of program modules 1316 may be stored, by way of example and not limitation, in main memory 1306, as may an operating system, one or more application programs, other program modules, and program data. The operating system, one or more application programs, other program modules, and program data, or a combination thereof, may each comprise an embodiment of a network environment. The components of computer 1302 may be embodied as program modules 1316 that generally perform the functions and / or methodologies of embodiments of the invention described herein. The systems of Fig. 1 may be implemented in one or more computer systems 1302, wherein, if implemented in multiple computer systems 1302, the computer systems may then exchange data over a network.

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

Claims

[1] A computer program product for prefetching cache resources for a write request (400) from a host (100) on tracks (302) temporarily stored in a cache (140), the tracks (302) being stored in a memory (104), the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therein that is executable to perform operations, the operations comprising: Releasing (504) cache resources held for tracks (302) in a write set (200) before receiving expected write operations for the tracks (302) in the write set (200); and Retrieving (602) cache resources for the tracks (302) in the write set (200), subsequent to releasing the cache resources to be used for the expected write operations to the tracks (302) in the write set (200). [2] The computer program product of claim 1, wherein the operations further comprise: Maintaining (606) a cursor (206) for the write set (200) indicating a track in the write set (200) for which to begin prefetching cache resources, wherein fetching cache resources comprises fetching (702) cache resources for sequential tracks (302) in the write set (200) from the track indicated by the cursor to a last track for which cache resources have been released. [3] The computer program product of claim 1, wherein retrieving cache resources comprises: Maintaining (606) a cursor (206) for the write set (200) that indicates a track in the write set (200) for which to begin prefetching cache resources, wherein fetching cache resources comprises fetching (802) cache resources for a fixed number of sequential tracks (302) in the write set (200), starting from a track following the cursor. [4] The computer program product of claim 1, wherein the cache resources for the write set (200) are held for write requests (400) received on a first channel from the host, the operations further comprising: Returning (1000) an error on a first write request (400) received on the first channel (112, 114) for a track in the write set (200) for which no cache resources are available; and Receiving (1002), from the host, a second write request (400) to a track on a second channel (112, 120) that the host sends in response to receiving the error on the first write request (400) on the first channel; where retrieving cache resources comprises: estimating (904) a number of write operations that the host may have sent on the second channel since releasing the cache resources; Setting (906) a starting track, which is the estimated number of write operations following a cursor pointing to a track in the write set (200) at which to begin prefetching cache resources after the cache resources have been released, and Retrieving (910) cache resources for sequential tracks (302) in the write set (200) starting from the starting track. [5] The computer program product of claim 4, wherein estimating the number of write operations the host may have performed comprises: Setting a write time for the host to complete a write request (400) on the second channel; and Estimating the number of write operations as a function of a quiesce time during which write requests (400) to the write set (200) were quiesced and the write time, wherein the estimated number of write operations is a function of the quiesce time divided by the write time. [6] The computer program product of claim 1, wherein the cache resources for the write set (200) are held for write requests (400) received on a first channel from the host, the operations further comprising: Returning (1000) an error on a first write request (400) received on the first channel (112, 114) for a track in the write set (200) for which no cache resources are available; and Receiving (1100), from the host, a second write request (400) to a track on a second channel (112, 120), which the host sends in response to receiving the error on the first write request (400) on the first channel, the second write request (400) identifying the write set (200), wherein cache resources for sequential tracks (302) in the write set (200) are retrieved starting at a track following the track described by the second write request (400). [7] The computer program product of claim 6, wherein the operations further comprise: in response to receiving the second write request (400) on the second channel, identifying the write set (200), setting (1108) a last track repeated field for the write set (200) to indicate a last track written by the second write request (400), wherein the cache resources are retrieved starting from a track following the track specified in the last track repeated field. [8] The computer program product of claim 6, wherein the second write request (400) further indicates whether the first write request (400) will be repeated (1106) on the first channel, wherein the cache resources are retrieved from the track following a track written by the second write request (400) in response to the second write request (400) indicating that the first write request (400) will not be repeated, the operations further comprising: Retrieving cache resources for sequential tracks (302) in the write set (200) starting from the track described by the second write request (400) in response to the second write request (400) indicating that the first write request (400) is being retried. [9] The computer program product of claim 6, wherein the cache resources are released to a volume comprising the write set (200) in response to quiescing write requests (400) on the first channel, the cache resources being retrieved in response to terminating the quiescing of the write requests (400) on the first channel. [10] A computer program product for sending cache resources to a memory controller that manages access to tracks (302) in a memory, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therein that is executable to perform operations, the operations comprising: Sending a first write request (400) to a track in a write set (200) on a first channel to the memory controller, wherein the cache resources for tracks (302) in the write set (200) are pre-allocated by the memory controller before receiving write requests (400) to the tracks (302) in the write set (200); Receiving (1000), from the memory controller, an error in response to the failure of the first write request (400); and Sending (1012) a second write request (400) for the track to which the failed first write request (400) was directed on a second channel different from the first channel in response to the failure of the first write request (400), wherein the second write request (400) causes the memory controller to retrieve cache resources for use for expected write requests (400) on tracks (302) in the write set (200) to be resent on the first channel. [11] The computer program product of claim 10, wherein the operations further comprise: Indicating in the second write request (400) whether the first write request (400) is repeated on the first channel, wherein the memory controller is caused to retrieve cache resources from the track described by the first write request (400) in response to the second write request (400) indicating that the first write request (400) is repeated on the second channel. [12] A system for prefetching cache resources for a write request (400) from a host to tracks (302) in a memory, the system comprising: a processor; a cache; and a computer-readable storage medium containing computer-readable program code which, when executed by the processor, carries out operations, whereby the operations comprise: Releasing cache resources held for tracks (302) in a write set (200) before receiving expected write operations for the tracks (302) in the write set (200); and Retrieving cache resources for the tracks (302) in the write set (200), subsequent to releasing the cache resources to be used for the expected write operations to the tracks (302) in the write set (200). [13] The system of claim 12, wherein the cache resources for the write set (200) are held for write requests (400) received on a first channel from the host, the operations further comprising: Returning an error on a first write request (400) received on the first channel for a track in the write set (200) for which no cache resources are available; and Receiving, from the host, a second write request (400) to a track on a second channel, which the host sends in response to receiving the error on the first write request (400) on the first channel; where retrieving cache resources comprises: Estimating a number of write operations that the host may have sent on the second channel since releasing the cache resources; Setting a starting track, which is the estimated number of write operations following a cursor pointing to a track in the write set (200) at which to begin prefetching cache resources after the cache resources have been released, and Retrieving cache resources for sequential tracks (302) in the write set (200) starting from the starting track. [14] The system of claim 12, wherein the cache resources for the write set (200) are held for write requests (400) received on a first channel from the host, the operations further comprising: Returning an error on a first write request (400) received on the first channel for a track in the write set (200) for which no cache resources are available; and Receiving, from the host, a second write request (400) to a track on a second channel, which the host sends in response to receiving the error on the first write request (400) on the first channel, the second write request (400) identifying the write set (200), wherein cache resources for sequential tracks (302) in the write set (200) are retrieved starting at a track following the track described by the second write request (400). [15] The system of claim 14, wherein the operations further comprise: in response to receiving the second write request (400) on the second channel, identifying the write set (200), setting a last track repeated field for the write set (200) to indicate a last track written by the second write request (400), wherein the cache resources are retrieved starting from a track following the track specified in the last track repeated field. [16] The system of claim 14, wherein the second write request (400) further indicates whether the first write request (400) will be repeated on the first channel, wherein the cache resources are retrieved from the track following a track written by the second write request (400) in response to the second write request (400) indicating that the first write request (400) will not be repeated, the operations further comprising: Retrieving cache resources for sequential tracks (302) in the write set (200) starting from the track described by the second write request (400) in response to the second write request (400) indicating that the first write request (400) is being retried. [17] The system of claim 14, wherein the cache resources are released to a volume comprising the write set (200) in response to quiescing write requests (400) on the first channel, the cache resources being retrieved in response to terminating the quiescing of the write requests (400) on the first channel. [18] A system for sending requests to a memory controller that manages access to tracks (302) in a memory, the system comprising: a processor; and a computer-readable storage medium having embodied therein computer-readable program code executable to perform operations, the operations comprising: Sending a first write request (400) to a track in a write set (200) on a first channel to the memory controller, wherein the cache resources for tracks (302) in the write set (200) are pre-allocated by the memory controller before receiving write requests (400) to the tracks (302) in the write set (200); Receiving, from the memory controller, an error in response to the failure of the first write request (400); and Sending a second write request (400) for the track to which the first write request (400) was directed on a second channel different from the first channel in response to the failure of the first write request (400), wherein the second write request (400) causes the memory controller to retrieve cache resources for use for expected write requests (400) on tracks (302) in the write set (200) to be resent on the first channel. [19] The system of claim 18, wherein the operations further comprise: Indicating in the second write request (400) whether the first write request (400) is repeated on the first channel, wherein the memory controller is caused to retrieve cache resources from the track described by the first write request (400) in response to the second write request (400) indicating that the first write request (400) is repeated on the second channel. [20] A method for prefetching cache resources for a write request (400) from a host to tracks (302) in a memory, the method comprising: Releasing cache resources held for tracks (302) in a write set (200) before receiving expected write operations for the tracks (302) in the write set (200); and Retrieving cache resources for the tracks (302) in the write set (200), subsequent to releasing the cache resources to be used for the expected write operations to the tracks (302) in the write set (200). [21] The method of claim 20, wherein the cache resources for the write set (200) are held for write requests (400) received on a first channel from the host, the method further comprising: Returning an error on a first write request (400) received on the first channel for a track in the write set (200) for which no cache resources are available; and Receiving, from the host, a second write request (400) to a track on a second channel, which the host sends in response to receiving the error on the first write request (400) on the first channel; where retrieving cache resources comprises: Estimating a number of write operations that the host may have sent on the second channel since releasing the cache resources; Setting a starting track, which is the estimated number of write operations following a cursor pointing to a track in the write set (200) at which to begin prefetching cache resources after the cache resources have been released, and Retrieving cache resources for sequential tracks (302) in the write set (200) starting from the starting track. [22] The method of claim 20, wherein the cache resources for the write set (200) are held for write requests (400) received on a first channel from the host, the method further comprising: Returning an error on a first write request (400) received on the first channel for a track in the write set (200) for which no cache resources are available; and Receiving, from the host, a second write request (400) to a track on a second channel, which the host sends in response to receiving the error on the first write request (400) on the first channel, the second write request (400) identifying the write set (200), wherein cache resources for sequential tracks (302) in the write set (200) are retrieved starting at a track following the track described by the second write request (400). [23] The method of claim 22, further comprising: in response to receiving the second write request (400) on the second channel, identifying the write set (200), setting a last track repeated field for the write set (200) to indicate a last track written by the second write request (400), wherein the cache resources are retrieved starting from a track following the track specified in the last track repeated field. [24] The method of claim 22, wherein the second write request (400) further indicates whether the first write request (400) will be repeated on the first channel, wherein the cache resources are retrieved from the track following a track written by the second write request (400) in response to the second write request (400) indicating that the first write request (400) will not be repeated, the method further comprising: Retrieving cache resources for sequential tracks (302) in the write set (200) starting from the track described by the second write request (400) in response to the second write request (400) indicating that the first write request (400) is being retried. [25] The method of claim 22, wherein the cache resources are released in response to quiescing write requests (400) on the first channel to a volume comprising the write set (200), wherein the cache resources are retrieved in response to terminating the quiescing of the write requests (400) on the first channel.

Images