After cache resources for tracks in the write set are released, cache resources are acquired for anticipated writes to tracks in the write set.

Abstract

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

Description

[Technical field]

[0001] The present invention relates to computer program products, systems, and methods for obtaining cache resources for anticipated writes to tracks in a write-set after cache resources for tracks in a write-set have been released. [Background technology]

[0002] In a storage environment, a host system may first communicate a read / write request to an attached storage system over a high-speed channel, such as a bus interface or a Peripheral Component Interconnect Express (PCIe) interface. For a read / write request over a high-speed channel that is expected to complete within a threshold time, the host system keeps the application thread for the read / write request in a spin loop while waiting for the request to complete. This saves processor time associated with a context switch to deactivate the thread and reactivate it in response to an interrupt when a response to the read / write request is received. If the data for a read / write request sent on the high-speed channel is not in cache, the storage system may fail the read / write request, and the host system may communicate the same read / write request over a storage area network via a host adapter, which is slower than processing an I / O request over a bus, such as a PCIe interface. Communicating a read / write request over the second channel requires the host system to perform a context switch from the task processing the read / write request to another task while waiting for the read / write request to complete. A context switch is costly because it requires the processor running the task to clear all registers and L1 and L2 caches for the new task, and then, once the new task is complete, reactivate the task that was context switched to and restore state data to the registers and L1 and L2 caches for the task that was context switched to while waiting for the read / write request to complete.

[0003] Certain read / write operations need to be completed within a threshold time or they are failed. To process a read or write request, the storage system must allocate cache resources, including resources and segments in the cache storage, and access track metadata to process the read / write request. The track metadata provides information about the format of data and record layout in the track that is necessary to perform reads and writes to the track. However, the allocation of cache resources, including access to metadata from the storage, comprises a significant portion of the latency in processing a read / write request.

[0004] There is a need in the art for improved techniques for prefetching cache resources for a host write request to a cache on a high speed channel when a write request to a track is received on the high speed channel. Summary of the Invention

[0005] A computer program product, system, and method are provided for prefetching cache resources for write requests from a host to tracks in storage cached in a cache. Prior to receiving an anticipated write for the tracks in the write set, cache resources held for a number of tracks in the write set are released. After the release of the cache resources, cache resources for the tracks in the write set are obtained for use in the anticipated write request to the tracks in the write set.

[0006] In the above embodiment, releasing cache resources for tracks in the write set makes those resources available for other requests, which is optimal when anticipated writes to tracks in the write set cannot continue, such as when access to the write set is quiesced due to events such as a long busy or unsupported condition or volume ineligibility due to other processes. After releasing the cache resources, reacquiring cache resources for the released tracks ensures that write requests sent by the host for the write set complete within the required threshold time, which is especially important for performance when host threads are spinning write request tasks for the write requests.

[0007] In yet another embodiment, cache resources are maintained for a write set for a write request received on a first channel from a host. A failure of the first write request received on the first channel is returned for a track in the write set for which cache resources are not available. A second write request for the track is received on a second channel from the host, the second write request being sent by the host in response to receiving the failure of the first write request on the first channel. Obtaining the cache resources includes estimating a number of writes that the host could have sent on the second channel since the cache resources were released, determining a starting track that is after a cursor pointing to tracks in the write set by the estimated number of writes to begin prefetching the cache resources after the cache resources are released, and obtaining cache resources for consecutive tracks in the write set from the starting track.

[0008] In the above embodiment, the number of writes that the host could perform on the second channel would be reduced by skipping prefetching those tracks that are presumed to have been written on the second channel since cache resources are no longer needed for those tracks that were written on the second channel. Thus, prefetching is optimized by starting prefetching from the first track in the write set that is likely not written by the write request sent on the second channel after the quiesce.

[0009] In yet another embodiment, cache resources are maintained for a write set for a write request received on a first channel from a host. A failure is returned for the first write request received on the first channel for tracks in the write set for which cache resources are not available. A second write request for the tracks is received on a second channel from the host in response to receiving the failure of the first write request on the first channel. The second write request identifies a write set, and cache resources are obtained for consecutive tracks in the write set starting with the track next to the track written by the second write request.

[0010] In the above embodiment, since the host is likely not to retry on the first channel writing a track that was successfully written on the second channel, pre-fetching of a track already written on the second channel is avoided by obtaining cache resources for the track next to the track written by the second write request on the second channel.

[0011] In yet another embodiment, in response to receiving a second write request identifying the write set on the second channel, a last track retried field for the write set is set to indicate the last track written by the second write request, and cache resources are obtained from the track next to the track indicated in the last track retried field.

[0012] In the above embodiment, cache resources after the last track written on the second channel are prefetched so that the host does not need to attempt to re-access on the first channel a track that has already been accessed on the second channel. In this manner, recording the last track written allows cache resources after the last track written to be prefetched, thereby obtaining cache resources only for tracks that are likely to be written on the first channel and avoiding obtaining cache resources for tracks that will not be written.

[0013] In yet another embodiment, the second write request further indicates whether the first write request is to be retried on the first channel. Cache resources are obtained from a track next to the track written by the second write request in response to the second write request indicating that the first write request is not to be retried. Cache resources are obtained for consecutive tracks in the write set from the track written by the second write request in response to the second write request indicating that the first write request is to be retried.

[0014] In the above embodiment, the host provides a hint as to whether a failed write request that is retried on the second channel will also be retried on the first channel. This hint enables optimization by prefetching cache resources from tracks written on the second channel so that the host also retries the write on the first channel, and cache resources are available for the write request on the first channel to allow completion of the first channel write.

[0015] A computer program product, system and method are provided for sending requests to a storage manager that manages access to tracks in a storage. A first write request to tracks in a write set is sent to a storage controller on a first channel. Cache resources for the tracks in the write set are pre-allocated by the storage controller prior to receiving the write request to the tracks in the write set. In response to the first write request, a failure is received from the storage controller. In response to the failure of the first write request, a second write request is sent on a second channel for the tracks written by the first write request. The second write request indicates a write set to cause the storage controller to acquire cache resources for tracks in the write set after the tracks indicated in the second write request. The acquired cache resources are used for anticipated write requests to tracks in the write set sent on the first channel.

[0016] In yet another embodiment, an indication is provided in the second write request of whether the first write request is to be retried on the first channel, and in response to the second write request indicating that the first write request is to be retried on the second channel, the storage controller is caused to obtain cache resources from the track to be written by the first write request.

[0017] In the above embodiment, the host can specify to the storage controller whether the host will retry on the first channel, allowing the storage controller to adjust prefetching of consecutive tracks in the write set after the last written track if the write request is not retried. Furthermore, if the host retries on the first channel a write request written on the second channel, this indication of retry in the write request on the second channel ensures that cache resources are acquired for the tracks written by the second channel write request for use during the request of the first channel write. Furthermore, if the write request on the second channel is retried, the last track retried field is not set to indicate the last track written by the write request, and cache resources are acquired for those tracks retried on the second channel. This optimizes prefetching operations by adjusting prefetching as needed and avoiding prefetching of cache resources for written tracks that are not rewritten by the write request on the first channel, so that cache resources do not need to be acquired when retry writes on the first channel are not needed. [Brief description of the drawings]

[0018] [Figure 1] 1 illustrates one embodiment of a storage environment. [Diagram 2] 1 illustrates one embodiment of writeset information for an established writeset. [Diagram 3] 1 illustrates one embodiment of a track access list entry in a track access list. [Figure 4] 1 illustrates one embodiment of a second channel write request sent on a second channel to retry a write request that failed on a first channel. [Diagram 5] 1 illustrates one embodiment of operations for handling a write-set quiesce. [Figure 6] 13 illustrates one embodiment of operations for handling the end of a quiesce of a write-set. [Figure 7] 1 illustrates one embodiment of operations for obtaining cache resources for anticipated write requests on a first channel when quiescing of a write set has ended. [Figure 8] 1 illustrates one embodiment of operations for obtaining cache resources for anticipated write requests on a first channel when quiescing of a write set has ended. [Figure 9] 1 illustrates one embodiment of operations for obtaining cache resources for anticipated write requests on a first channel when quiescing of a write set has ended. [Figure 10] FIG. 1 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 a first channel to write to a track; [Figure 11] 1 illustrates one embodiment of operations performed by a storage system to process a second channel write request from a host. [Figure 12] 1 illustrates one embodiment of operations for obtaining cache resources for anticipated write requests on a first channel when quiescing of a write set has ended. [Figure 13] 1 illustrates one embodiment of a computer architecture that may be used in the described embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] To allow other processes to access tracks held for a write set, access to the write set can be quiesced if there is an event that prevents write access to the tracks for an extended period of time, such as a long busy or unsupported copy service condition or volume ineligibility due to other processes. Quiescing access to tracks in a write set frees cache resources for the tracks upon write. Releasing cache resources results in failure of first channel write requests to retry writing to tracks in the quiesced write set if there are no pre-allocated cache resources for those write requests when the request is received.

[0020] By accessing the cache resources before the write request on the first channel after an event that has resulted in the release of cache resources, such as the quiescing of a write set, latency in processing the access request is minimized. Furthermore, by accessing the cache resources before the access request, the described embodiments increase the likelihood that a write request sent by the host on the first high-speed channel will complete within the threshold time required to process an access request on the first channel that requires high-speed processing. This keeps the time that the host thread is spinning on a write request task for a write request sent on the bus interface within an acceptable time threshold. However, if cache resources were not allocated for the requested target track after it was released as a result of the quiescing of other operations, and before the request, then the retransmitted write request on the first channel may fail again because it is unlikely that the write request can be completed within the threshold time, assuming that cache resources would need to be allocated. The failure of the write request on the first channel causes the host to retransmit the write request on the second channel. In processing the access request, the processing of the write request on the second channel allocates the requested cache resources.

[0021] The described embodiments provide an improvement to computer techniques for prefetching cache resources by reacquiring cache resources for tracks in a write set that have been released due to quiescing or other processes. The described embodiments use techniques that estimate where a write request on a first channel will begin if a host retries a failed first channel write request on a second channel. In this manner, the storage system optimizes prefetching of cache resources by reacquiring cache resources for tracks in a write set that are likely to be written to by a later write request on the first channel, and avoids reacquiring cache resources for tracks in a write set that will not be accessed again by a write request on the first channel.

[0022] 1 illustrates an 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, for accessing tracks within volumes 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 that includes 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 device 104. The host 100 includes hardware for communicating the read and write requests over two different channels. The "first channel" may include a bus interface such as Peripheral Component Interconnect Express (PCIe), including bus 112, bus switch 114 for connecting one or more devices on bus 112, including processor complex 108, memory system 110, and bus host adapter 116 for extending the bus interface to storage system 102 through external bus interface cable 118. Additional bus interface technologies may be utilized 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.

[0023] A "second channel" for connecting the host 100 and the storage system 102 may use a network host adapter 120 connected to the bus 112 that connects to a separate network 122 over which the host 100 and the storage system 102 additionally communicate. The first channel through the bus interface may include a faster access channel than the second channel that uses an interface to the network 122 through the network host adapter 120.

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

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

[0026] The write access cache manager 142 prefetches cache resources, including metadata, in 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.

[0027] A track may include any unit of data organized within storage 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 device, etc.

[0028] The write access manager 142 maintains cache management information 146 in memory 138 for managing 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 of the track in the cache 140 to a cache control block 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 contains cache control blocks, and for each track in the cache 140, there is one cache control block that provides metadata about the track in the cache 140. The track index 148 associates a track with a cache control block that provides information about the track in the cache 140. When it is determined that the cache LRU list 152 is full or has reached a threshold level, tracks are demoted from the LRU list 152 to make room for more tracks to be staged into the cache 140 from the storage 104.

[0029] The cache management information 146 may further include write set information 200 of write sets of tracks established by the host 100 for tracks to write on the first channel. The write access manager 140 may prefetch cache resources for tracks in the write set before receiving a write transaction. The host 100 may establish multiple write sets for multiple ranges of tracks for which track resources will be allocated in anticipation of multiple streams of consecutive write transactions to different ranges of tracks.

[0030] Prior to sending a write request for consecutive write transactions, the host operating system 111 may establish a write set 200 for a range of tracks 204 and have the write access manager 142 pre-allocate cache resources for the write set in anticipation of consecutive write transactions that are likely to be soon directed to those tracks indicated in the write set. These pre-allocated cache resources reduce the latency of processing consecutive write requests when they are eventually received. Furthermore, by allocating cache resources for a limited number (a fixed number) of a first subset of tracks in the write set, cache resources are reserved only for tracks that are most likely to be written as part of a consecutive write stream. Furthermore, the number of tracks for which cache resources are reserved is limited such that those cache resources are available for access by other processes in the host operating system 111 or other connected hosts 100.

[0031] The cache resources maintained and accessed for a track in track range 204 may include a segment in cache 140 used to write the track, a segment in non-volatile storage if a copy of the written track is stored in non-volatile storage in the same cluster or a different cluster, track metadata for the track, as well as other types of cache resources required to process write transactions directed to the track.

[0032] In certain embodiments, there may be multiple hosts 100 connecting to the storage system 102 via first and second channels to access tracks in the storage device 104. In such a case, the storage system 102 has 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.

[0033] In one embodiment, the bus interfaces 112, 114, 116, 118, 124a, 124b, 126, and 128 may include Peripheral Component Interconnect Express (PCIe) bus interface technology. In alternative embodiments, the bus interfaces 112, 114, 116, 118, 124a, 124b, 126, and 128 may utilize suitable bus interface technologies other than PCIe. The bus host adapters 116 and 128 may include a PCIe host adapter that provides an interface for connecting to the PCIe cable 118. The network 122 may include a storage area network (SAN), a local area network (LAN), a wide area network (WAN), a fiber connection (FICON®), the Internet, an intranet, etc., and the network host adapters 120, 134 may provide a network 122 connection between the host 100 and the storage system 102. (FICON is a registered trademark of International Business Machines Corporation worldwide.)

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

[0035] The storage devices 104 in the disk enclosure 106 can include different types or classes of storage devices such as magnetic hard disk drives, solid state storage devices (SSDs) made of solid state electronics, EEPROMs (Electrically Erasable Programmable Read Only Memory), flash memory, flash disks, random access memory (RAM) drives, storage class memory (SCM) such as phase change memory (PCM), resistive random access memory (RRAM), spin transfer torque memory (STT-RAM), conductive bridge RAM (CBRAM), magnetic hard disk drives, optical disks, tapes, etc. Volumes in the storage space can further be comprised of arrays of devices such as Just a Bunch of Disks (JBOD), Direct Access Storage Devices (DASD), Redundant Array of Independent Disks (RAID) arrays, virtualization devices, etc. Additionally, the storage devices 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, having a slower data transfer rate than a second type of storage device, e.g., an SSD.

[0036] FIG. 2 illustrates write set information 200 for an established write set for receiving write requests on a first channel. i2 illustrates an embodiment of an instance of the write set 200, including a write set identifier (ID) 202 providing a unique identifier for the write set, a range of tracks 204 for which successive write transactions on a first channel are expected and for which cache resources should be accessed prior to the successive write transactions, and, for each track within the range of tracks 204, a cache resource is reserved for the track and a write set ID 202 is established for the write set 200. i 1 ), a prefetch cursor 206 indicating a track within the range of tracks 302 at which cache resources should begin to be allocated for successive write transactions in the write set 202; a last track freed field 208, used when the embodiment of FIG. 7 is implemented, indicating the last track for which cache resources were freed; and a last track retried field 210, used in the embodiments of FIGS. 10, 11 and 12, which includes tracks within the range of tracks 204 that were written by write requests sent on the second channel (120, 122, 134 in FIG. 1 ).

[0037] In certain embodiments, the prefetch cursor 206 can be set during normal operation to point to the write access manager 142's prediction of where in the track the host 100 is writing (if actively writing) or will write next (if not actively writing). The prefetch cursor 206 points to where the write access manager 142 determines the host 100 is in its process.

[0038] FIG. 3 illustrates a track access list entry 300 in a track access list 300 showing a track identifier (ID) 302, a cache resource reserved flag 304 indicating that cache resources are reserved for the track 302, and a track write flag 306 indicating whether the track 302 has been written to since the write set 202 was established.i 1 shows one embodiment of the present invention.

[0039] FIG. 4 illustrates one embodiment of a second channel write request 400 received on a second channel from a host 100, including a write operation code 402, an extent range definition 404 of a subset of tracks in a write set 408 to which one or more subsequent consecutive write transactions 406 are directed, and a retry flag 410 on the first channel that indicates whether the write transaction 406 in the second channel write request 400 is to be retried later on the faster first channel.

[0040] 5 illustrates one embodiment of operations performed by write access manager 142 to handle quiescing of a write set. Quiescing may be caused by a volume containing the write set becoming ineligible, an extended period of no input / output (I / O) activity on the tracks associated with the write set, or a copy operation, such as replication or mirroring, directed to the volume containing the write set, or other cause of quiescing of a write set. i After processing the quiesce (block 500), the write access manager 142 allocates the write set 200 i For track access list 300, write set 200 i Track access list entry 300 in track access list 300 for i The tracks in the write set for which cache resources have been allocated are determined (at block 502), as indicated by the track access list entries 300 in the write set field 304. The cache resources are released (at block 504) for the determined tracks. The write access manager 142 updates the track access list entries 300 for all tracks for which cache resources have been released to indicate that there are no retained cache resources 304. i(at block 506). In the embodiment of Figure 7, the last track released field 208 is set to the last track in the write set for which cache resources were released (at block 508). In the embodiment of Figures 11 and 12, the last track retried 210 is set to null to indicate that there have been no writes to the track since the quiesce ended (at block 510).

[0041] 5, processing the quiescing of tracks in the write-set frees up cache resources for those tracks in the write-set and makes them available for other cache operations. Cache resources will need to be acquired again from the prefetch cursor 206 if writes on the first channel continue for the write-set.

[0042] FIG. 6 illustrates one embodiment of operations performed by write access manager 142 to process the end of quiesce for a write set. Upon processing the end of quiesce (at block 600), write access manager 142 obtains cache resources for consecutive tracks from prefetch cursor 206 (at block 602) for use in anticipated write requests to tracks in the write set according to one of the embodiments of FIG. 7, FIG. 8, FIG. 9, FIG. 12. Prefetch cursor 206 may have been set prior to quiesce during normal track prefetch operations in anticipation of write transfers from host 100. Write access manager 142 indicates all tracks that will be accessed / hold cache resources by setting field 304 (FIG. 3) in track access list 300 to indicate that cache resources are held for track 302 (at block 604). To enable prefetching of the freed cache resource, the prefetch cursor 206 is set (at block 606) to point to the start of the track from which the cache resource was obtained.

[0043] In the embodiment of FIG. 6, after the quiescing of the write set is completed, cache resources are acquired for tracks within the write that are expected to receive further writes on the first channel. The prefetching starts from the prefetch cursor 206 that was set before the quiesce during normal track prefetching. In this way, the prefetch cursor points to the start of the track for which the cache resources have been released. Acquiring the cache resources before receiving the write request on the first channel allows the write request to proceed because the transaction can be processed very quickly with acceptable latency using the pre-allocated cache resources.

[0044] If cache resources are not allocated to allow low latency processing of the write request, the write request fails because the transaction is likely not to complete within the fast time threshold. This decision is made to avoid host delays in processing other tasks while the host processor spins on the thread processing the write request while waiting for the write request to complete. If cache resources are already pre-allocated, the write is likely to be able to complete on the first channel within the latency threshold required to avoid the host processor holding the thread too long, causing other I / O requests to be queued and delayed. Returning failure when cache resources are not pre-allocated deactivates the host thread waiting on the write request task, allowing the host processor to context switch to processing other tasks, and then retrying the write request on the second network channel during the context switch.

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

[0046] Figure 7 illustrates one embodiment of operations performed by write access manager 142 for the prefetch operation in block 602 of Figure 6. Upon initiating a prefetch operation in block 602 of Figure 6 to obtain cache resources for a first channel write request (in block 700), write access manager 142 retrieves the write set 200 up to the last track 208 released from prefetch cursor 206. i Obtain cache resources for the track in (at block 702)

[0047] In the embodiment of FIG. 7, the write access manager 142 acquires resources for all tracks for which cache resources were released in block 504 (FIG. 5) and allows writing to continue for the write set on the fast first channel after quiescing ends.

[0048] Figure 8 illustrates one embodiment of operations performed by write access manager 142 to perform the prefetch operation of block 602 of Figure 6. Upon initiating the prefetch operation of block 602 of Figure 6 (at block 800) to obtain cache resources for a first channel write request, write access manager 142 accesses the write set 200 behind prefetch cursor 206. i A cache resource for a fixed number of contiguous tracks in the memory area is obtained (at block 802).

[0049] 8 embodiment, write access manager 142 obtains resources for a fixed number of tracks starting from the track next to the track pointed to by the prefetch cursor under the assumption that host 100 would have retried a write request on the second channel for the first of the tracks identified by prefetch cursor 206 for which cache resources have been freed. By skipping the track identified by prefetch cursor 206 or the track next to the first track in the write set for which cache resources have been freed, write access manager 142 avoids prefetching cache resources for tracks that are likely to have been written to by a write request sent on the second channel after the write request failed on the first channel.

[0050] 9 illustrates one embodiment of operations performed by write access manager 142 for a prefetch operation at block 602 of FIG. 6 by estimating the number of writes that host 100 could have sent on the second channel since cache resources were released as part of a quiesce of the write set. Upon initiating a prefetch operation at block 602 of FIG. 6 to obtain cache resources for a first channel write request (at block 900), write access manager 142 determines (at block 902) a second channel write time for the host to complete the write request on the second channel, which may be a preset value or an average of the time it takes recent second channel write requests to complete. Write access manager 142 estimates (at block 904) the number of writes that the host performed on the second channel during the quiesce 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 determined (at block 906) as the number of tracks after the prefetch cursor 206 that contains the estimated number of writes. The prefetch cursor 206 is then set to the starting track (at block 908). The write access manager 142 obtains cache resources for a fixed number of tracks from the prefetch cursor, including the tracks in the prefetch cursor 206 (at block 910).

[0051] In the embodiment of Figure 9, the write access manager 142 estimates the number of writes that the host could perform on the second channel during quiesce to skip acquiring cache resources for those tracks that are presumably already written on the second channel because cache resources are no longer needed for those tracks that were written on the second channel. In this way, the embodiment of Figure 9 optimizes prefetching by starting prefetching after quiesce from the first track in the write set that is likely not written by the write request 400 sent on the second channel.

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

[0053] FIG. 10 illustrates a write set 200 sent on a first channel from storage system 102. i 10 illustrates one embodiment of operations performed by operating system 111 of host 100 upon receiving a failure of a write request to a track in a first channel. Upon receiving the failure (at block 1000), host 100 generates (at block 1002) a write request 400 on a second channel for the track written by the failed write request on the first channel. A write set 200 of tracks to rewrite on the second channel. iis indicated in the write set field 408 (at block 1004). If the host 100 is configured to retry the write request 400 on the first channel (at block 1006), then a retry flag 410 on the first channel is set (at block 1008) to indicate that the write request 400 is to be retried on the first channel. If the write request 400 is not to be retried on the first channel (at block 1006), then the retry flag 410 on the first channel is set (at block 1010) to indicate that the write request 400 is not to be retried on the first channel. After setting the flag 410 at block 1008 or 1010, the write request 400 is then sent to the storage system 102 on the second channel (at block 1012).

[0054] 11 illustrates one embodiment of operations performed by write access manager 142 of storage system 102 to process a write request 400 from host 100 on a second channel during quiescing of writes to the write set. Upon receiving write request 400 on the second channel (at block 1100), write access manager 142 determines (at block 1102) whether write request 400 indicates a write set 408 established for the write request on the first channel. If (at block 1102) a write set 408 is not indicated, the second write request is processed (at block 1104). If a write set 408 is indicated (at block 1102) and the retry flag 410 on the first channel indicates (at block 1106) that the write request that caused the received write request 400 to fail on the first channel will not be retried on the first channel, then the last track retried field 210 for the write set 408 is set (at block 1108) to the track next to the track (or last track) written by the write request 400. If the retry flag 410 on the first channel indicates (at block 1106) that the write request will be retried on the first channel or after setting the last track retried field 210 (at block 1108), then the second write request 400 is processed (at block 1104) to write to a track in the write set.

[0055] FIG. 12 shows the write set 200 i After the quiescing of access to the write set 200 i12 illustrates one embodiment of operations performed by write access manager 142 to prefetch cache resources for tracks in a write set. Upon initiating a prefetch operation (at block 1200), if the last track field 210 retried indicates a track, then prefetch cursor 206 is set to the track indicated in the last track field 210 retried. If the last track field 210 retried does not indicate a track (at block 1202), or after setting prefetch cursor 206 (at block 1204), write access manager 142 obtains cache resources for a fixed number of contiguous tracks in the write set from prefetch cursor 206.

[0056] In the embodiments of Figures 10, 11, and 12, if the write request 400 is also retried on the first channel, the write access manager 142 also needs to obtain cache resources for the track written by the write request 400 in order to successfully process the first channel write request. To ensure that cache resources are obtained for the track written by the second channel write request 400, the last track retried field 210 is not set to indicate the track last written by the write request 400 so that cache resources are obtained from the current prefetch cursor 206 position. If the write request is not retried on the first channel, the write access manager 142 does not need to prefetch cache resources for the track written by the second channel write request 400. In such a case, to skip the prefetch for the track that was just written, the last track retried field 210 is set to the next track after the last track written by the write request 400 such that the write access manager 142 will begin prefetching after the quiesce from the track in the write set next to the track written by the second channel write request 400.

[0057] 10, 11, and 12, the host 100 can specify to the write access manager 142 whether the host retries a write request on the first channel to enable the write access manager 142 to adjust the prefetch cursor 206 to a contiguous track in the write set after the last written track if the write request is not retried. This optimizes prefetch operations by adjusting the prefetch cursor 206 as necessary to avoid prefetching cache resources for written tracks that are not accessed by the write request on the first channel.

[0058] In one embodiment, the second channel includes a FICON® link, which is an International Business Machines Corporation (IBM) proprietary name for the ANSI FC-SB-3 Single-Byte Command Code Sets-3 Mapping Protocol for Fibre Channel (FC), the first channel includes an IBM zHyperLink, and the host operating system 111 includes Z / OS®, and then the host 100 can retry failed zHyperLink (first channel) writes over the FICON interface (second channel) by appending new fields such as a retry write flag 410 and a write set ID 408 on the first channel to associate the FICON IO with a write set 408. This additional information allows the write access manager 142 to retrieve the write set information 200 for a particular track. i The host 100 may then set the last retried track field 210 in the zHyperLink (first channel) to control where the storage system 102 should point the write set to. Once the quiescing of the write set is complete, the host 100 will begin reacquiring the tracks after the last retried track 210. The host 100 may further have a software hint that tells the storage system 102 that the host will retry writes on the zHyperLink (first channel) to control where the storage system 102 should point for prefetching.

[0059] The present invention may be embodied as a system, method, or computer program product, or a combination thereof. The computer program product may include a computer readable storage medium or media having computer readable program instructions for causing a processor to perform aspects of the present invention.

[0060] A computer readable storage medium may be any tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but 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 of the above. A non-exhaustive list of more specific examples of computer readable storage media includes the following: portable computer diskettes, 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 compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the above. As used herein, a computer-readable storage medium is not to be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or an electrical signal sent through a wire.

[0061] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage in a computer readable storage medium in the respective computing / processing device.

[0062] The computer readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Java, Smalltalk, C++, and traditional 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, partly on the user's computer as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions to individualize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the invention.

[0063] Aspects of the present invention are described 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.

[0064] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions executed by the processor of the computer or other programmable data processing apparatus create means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer program instructions may also be stored in a computer readable medium capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, whereby the instructions stored in the computer readable medium include an article of manufacture including instructions implementing aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0065] 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 operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device provide a process for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0066] 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 flowcharts may represent a module, segment, or portion of code, including one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions shown in the blocks may occur in a different order than that shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or these blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that executes the specified functions or operations, or executes a combination of dedicated hardware and computer instructions.

[0067] The computational 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 computer system 1302 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 the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 1302 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0068] As shown in Figure 13, a computer system / server 1302 is shown in the form of 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, a system memory 1308, and a bus 1306 that couples 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 bus or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0069] Computer system / server 1302 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system / server 1302 and includes both volatile and nonvolatile media, removable and non-removable media.

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

[0071] A program / utility 1314 having a set (at least one) of program modules 1316 can be stored in the memory 1306, as can, for example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, can include an implementation of a networking environment. The components of the computer 1302 can generally be implemented as program modules 1316 that perform the functions and / or methods of the embodiments of the invention described herein. The system of FIG. 1 can be implemented in one or more computer systems, and when they are implemented in multiple computer systems 1302, then the computer systems can communicate over a network.

[0072] 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, one or more devices that allow a user to interact with the computer system / server 1302, or any device that allows the computer system / server 1302 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.), or a combination thereof. Such communication may occur via an input / output (I / O) interface 1322. Additionally, 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), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 1324. As shown, the network adapter 1324 communicates with other components of the computer system / server 1302 via a bus 1308. Although not shown, it is understood that other hardware and / or software components may be used in combination with computer system / server 1302, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems.

[0073] The terms "an embodiment," "embodiment," "embodiments," "the embodiment," "the embodiment," "one or more embodiments," "some embodiments," and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)," unless otherwise specified.

[0074] The terms "including," "comprising," and "having" and variations thereof mean "including but not limited to," unless otherwise specified.

[0075] An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless specifically stated.

[0076] The terms "a," "an," and "the" mean "one or more" unless otherwise specified.

[0077] Devices that are in communication with each other need not be in continuous communication with each other unless otherwise specified. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

[0078] A description of an embodiment having several components in communication with each other does not imply that all such components are required, but rather, various optional components are described to illustrate various possible embodiments of the present invention.

[0079] When a single device or article is described herein, it will be readily understood that more than one device / article may be substituted for the single device / article (whether they cooperate or not). Similarly, when more than one device or article is described herein (whether they cooperate or not), it will be readily understood that a single device / article may be substituted for more than one device or article, or a different number of devices / articles may be substituted for the number of devices or programs shown. The functionality or features or both of a device may alternatively be embodied by one or more other devices not explicitly described as having such functionality / features. Thus, other embodiments of the invention need not include a device per se.

[0080] The above description of various embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims appended hereto below.

Claims

1. 1. A computer program product for prefetching cache resources for a write request from a host to a track in a cached storage, the computer program product causing a computer to perform operations, the operations comprising: releasing cache resources held for a number of tracks in a write-set prior to receiving an anticipated write for the tracks in the write-set; obtaining cache resources for tracks in the write set after the release of the cache resources for use in the anticipated write to the tracks in the write set; Including, the operations further include maintaining a cursor for the write set indicating a track in the write set for initiating prefetching of cache resources, and obtaining the cache resources includes obtaining cache resources for consecutive tracks in the write set starting from the track indicated by the cursor through a last track for which cache resources have been released; Computer program.

2. A computer program product for prefetching cache resources for a write request from a host to a track in storage cached in a cache, the computer program product causing a computer to perform operations, the operations comprising: releasing cache resources held for a number of tracks in a write-set prior to receiving an anticipated write for the tracks in the write-set; obtaining cache resources for tracks in the write set after the release of the cache resources for use in the anticipated write to the tracks in the write set; Including, obtaining the cache resource includes maintaining a cursor over the write set that indicates a track in the write set to initiate prefetching of the cache resource, and obtaining the cache resource includes obtaining cache resources for a fixed number of consecutive tracks in the write set starting at a next track of the cursor. Computer program.

3. A computer program product for prefetching cache resources for write requests from a host to tracks in storage cached in a cache, the computer program product causing a computer to perform an operation in which the cache resources are retained for the write sets for write requests received on a first channel from the host, The operation includes: releasing cache resources held for a number of tracks in a write-set prior to receiving an anticipated write for the tracks in the write-set; returning a failure to a first write request received on the first channel for a track in a write set for which cache resources are not available; receiving, on a second channel from the host, a second write request to a track sent by the host in response to receiving the failure of the first write request on the first channel; obtaining cache resources for tracks in the write set after the release of the cache resources for use in the anticipated write to the tracks in the write set; Including, Obtaining the cache resource includes: estimating the number of writes that the host was able to send on the second channel since the cache resource was released; determining a starting track after the estimated number of writes that points to a track in the write set to begin prefetching cache resources after the cache resources are freed; obtaining cache resources for successive tracks in the write set from the starting track; Including, Computer program.

4. estimating the number of writes that the host was able to perform determining a write time for the host to complete a write request on the second channel; estimating the number of writes as a function of a quiescent time during which write requests to the write set were quiesced and the write time, the estimated number of writes being a function of the quiescent time divided by the write time; 4. The computer program product of claim 3, comprising:

5. A computer program product for prefetching cache resources for write requests from a host to tracks in storage cached in a cache, the computer program product causing a computer to perform an operation in which the cache resources are retained for the write sets for write requests received on a first channel from the host, The operation includes: releasing cache resources held for a number of tracks in a write-set prior to receiving an anticipated write for the tracks in the write-set; returning a failure to a first write request received on the first channel for a track in a write set for which cache resources are not available; receiving, on a second channel from the host, a second write request to a track sent by the host in response to receiving the failure of the first write request on the first channel; obtaining cache resources for tracks in the write set after the release of the cache resources for use in the anticipated write to the tracks in the write set; Including, the second write request identifies the write set, and cache resources are obtained for consecutive tracks in the write set starting with a track next to the track written by the second write request. Computer program.

6. the operations further include, in response to receiving the second write request on the second channel identifying the write set, setting a last retried track field for the write set to indicate a last track written by the second write request; the cache resource is obtained from a track next to the track indicated in the last retried track field; 6. A computer program product according to claim 5.

7. the second write request further indicates whether the first write request is to be retried on the first channel, and in response to the second write request indicating that the first write request is not to be retried, the cache resource is obtained from the track next to the track written by the second write request; The operation includes: obtaining cache resources for consecutive tracks in the write set from the track written by the second write request in response to the second write request indicating that the first write request is to be retried; The computer program product of claim 5 , further comprising:

8. 6. The computer program product of claim 5, wherein the cache resources are released in response to quiescing of write requests on the first channel to a volume including the write set, and the cache resources are acquired in response to termination of the quiescing of the write requests on the first channel.

9. 1. A computer program for sending a request to a storage controller that manages access to tracks in a storage, the computer program causing a computer to perform operations, the operations comprising: sending a first write request to tracks in a write set on a first channel to the storage controller, where cache resources for tracks in the write set are pre-allocated by the storage controller prior to receiving the write request to the tracks in the write set; receiving a failure from the storage controller in response to the first write request; in response to the failure of the first write request, sending a second write request on a second channel for the tracks written by the first write request, the second write request indicating the write set to cause the storage controller to obtain cache resources for tracks in the write set after the tracks indicated in the second write request, the obtained cache resources being for use in anticipated write requests to tracks in the write set sent on the first channel; A computer program comprising:

10. The operations further include indicating in the second write request whether the first write request is to be retried on a first channel; in response to the second write request indicating that the first write request is to be retried on a second channel, the storage controller is caused to obtain cache resources from the track being written by the first write request.

10. A computer program product as claimed in claim 9.

11. 1. A system for prefetching cache resources for a write request from a host to a track in a storage device, comprising: A processor; Cache and a computer readable storage medium; A system in which the computer-readable storage medium stores a computer program as claimed in any one of claims 1 to 8, and each operation of the computer program is executed by the processor.

12. 1. A system for sending requests to a storage controller that manages access to tracks in a storage, comprising: A processor; a computer readable storage medium; A system in which the computer-readable storage medium stores the computer program according to claim 9 or 10, and each operation of the computer program is executed by the processor.

13. 1. A method for prefetching cache resources for write requests from a host to tracks in a storage, the cache resources being reserved for the write set for write requests received on a first channel from the host; releasing cache resources held for a number of tracks in a write-set prior to receiving an anticipated write for the tracks in the write-set; returning a failure to a first write request received on the first channel for a track in a write set for which cache resources are not available; receiving, on a second channel from the host, a second write request to a track sent by the host in response to receiving the failure of the first write request on the first channel; obtaining cache resources for tracks in the write set after the release of the cache resources for use in the anticipated writes to the tracks in the write set; Including, Obtaining the cache resource includes: estimating the number of writes that the host was able to send on the second channel since the cache resource was released; determining a starting track after the estimated number of writes that points to a track in the write set to begin prefetching cache resources after the cache resources are freed; obtaining cache resources for successive tracks in the write set from the starting track; A method comprising:

14. A method for prefetching cache resources for write requests from a host to tracks in a storage, the cache resources being held for the write set for write requests received on a first channel from the host; releasing cache resources held for a number of tracks in a write-set prior to receiving an anticipated write for the tracks in the write-set; returning a failure for a first write request received on the first channel for a track in a write set for which cache resources are not available; receiving, on a second channel from the host, a second write request to a track sent by the host in response to receiving the failure of the first write request on the first channel; obtaining cache resources for tracks in the write set after the release of the cache resources for use in the anticipated writes to the tracks in the write set; Including, the second write request identifies the write set, and cache resources are obtained for consecutive tracks in the write set starting with a track next to the track written by the second write request.

15. responsive to receiving the second write request identifying the write set on the second channel, setting a last retried track field for the write set to indicate a last track written by the second write request; the cache resource is obtained from a track next to the track indicated in the last retried track field; The method of claim 14.

16. the second write request further indicates whether the first write request is to be retried on the first channel, and in response to the second write request indicating that the first write request is not to be retried, the cache resource is obtained from the track next to the track written by the second write request; The method comprises: obtaining cache resources for consecutive tracks in the write set from the track written by the second write request in response to the second write request indicating that the first write request is to be retried; The method of claim 14 further comprising:

17. 15. The method of claim 14, wherein the cache resources are released in response to quiescing of write requests on the first channel to a volume that includes the write set, and the cache resources are acquired in response to termination of the quiescing of the write requests on the first channel.

18. A computer readable storage medium having stored thereon a computer program according to any one of claims 1 to 10.

Images