Garbage Collection in Data Storage Systems

Abstract

Garbage collection is performed on a virtualized storage system whose virtual address space is addressed in disk areas. Valid data in a source disk area is copied to a target disk area via a cache. After all valid data in the source disk area is copied to one or more destination disk areas, the source disk area can be reused. Only after determining that one or more destination disk areas receiving valid data copied from the source disk area are full, the source disk area is released for reuse, and the valid data copied from the source disk area to the destination disk area via the cache is cleared from the cache.

Description

Technical Field

[0001] The present invention relates to garbage collection in data storage systems. Background Art

[0002] A popular strategy for performing writes in a data storage system is typically to write a new data range in a data domain. The advantage of this strategy is that a RAID (Redundant Array of Independent Disks) array can be updated without performing any reads from the disks.

[0003] A typical "write" will do the following: an input-output (IO) for a given volume will be received, with an address, size, and some data. The storage allocator will allocate a storage location on the physical domain for that volume. The IO path will then write to that location on the physical domain. After the write is complete, the forward and reverse lookup structures are updated, and the IO is completed. As part of the forward lookup update, the log is also updated.

[0004] A typical "read" will check the forward lookup structure to identify where the data is located on the data domain. The data domain will then be read and the data at that location will be returned to the user. Summary of the Invention

[0005] Various embodiments relate to a method for performing garbage collection in a storage system, wherein a virtual address space is mapped to a physical address space, the virtual address space is addressed in disk extents, and the storage system has one or more processors, a plurality of storage devices, and a cache memory. The method may include selecting a first destination disk extent as a current destination disk extent for receiving garbage collected data, and selecting a first source disk extent as a current source disk extent for performing garbage collection, the current source disk extent including one or more portions of valid data. The method may also include determining whether the destination disk extent selected as the current destination disk extent for receiving garbage collected data is full. The method may include determining whether the source disk extent selected as the current source disk extent for performing garbage collection includes one or more portions of valid data that have not been copied to the destination disk extent. In addition, in response to determining that the current destination disk extent for receiving garbage collected data is not full and determining that the current source disk extent for performing garbage collection includes one or more portions of valid data that have not been copied to the destination disk extent, the method may include copying one of the portions of valid data that have not been copied to the destination disk extent from the current source disk extent to the current destination disk extent via the cache memory. Additionally, in response to determining that the current destination disk area for receiving garbage-collected data is full, the method may include flushing the valid data copied to the current destination disk area via the cache memory out of the cache memory. Additionally, after flushing the valid data to be moved to the current destination disk area out of the cache memory, the method may include releasing the physical address space mapped to the virtual address space of the one or more source disk areas in which all valid data copied to the current destination disk area via the cache memory is stored as available for writing.

[0006] Various embodiments of the garbage collection method may include, in response to determining that the current destination extent for receiving garbage collected data is full, selecting a second destination extent as the current destination extent for receiving garbage collected data.

[0007] Various embodiments of the garbage collection method may include: in response to determining that the second destination disk area for receiving garbage collected data is full, clearing the valid data copied to the current destination disk area via the cache memory from the cache memory, wherein the valid data copied to the current destination disk area via the cache memory is cleared from the cache memory in the same order as the order in which the destination disk area is determined to be full.

[0008] Various embodiments of the garbage collection method may include selecting a second source disk as the current source disk to be garbage collected in response to determining that the current source disk to be garbage collected does not include a portion of valid data that has not been copied to the destination disk.

[0009] Various embodiments of the garbage collection method may include: controlling the release of physical address space after a cache clear of a destination disk area by assigning a sequence number to each destination disk area, each sequence number allowing the search of the source disk area whose garbage collection has been completed by copying data into the destination disk area, storing the sequence number of the earliest destination disk area that has not yet been cleared as a low-watermark sequence number, and storing the sequence number of the current destination disk area assigned for garbage collection from the source disk area as a high-watermark sequence number, wherein the low-watermark sequence number is incremented when the earliest destination disk area is cleared from the cache memory, and the high-watermark sequence number is incremented when another destination disk area is selected for garbage collection.

[0010] Various embodiments of the garbage collection method may include: wherein, in response to determining that the available virtual address space is less than a threshold: suspending the copying of valid data from the source disk area to the destination disk area; and releasing the physical address space of the virtual address space mapped to at least one destination disk area having a sequence number between the low watermark value and the high watermark value as available for writing.

[0011] Various embodiments of the garbage collection method may include: maintaining a log storing recovery information for destination disk areas having sequence numbers between the low watermark value and the high watermark value, the recovery information including a mapping between source disk areas whose valid data has undergone garbage collection and corresponding destination disk areas.

[0012] Various embodiments of the garbage collection method may include: in response to determining the loss of cache content during garbage collection, using the recovery information to rebuild a forward lookup metadata structure that links a virtual address space to a physical address space of the source disk area identified in the recovery information.

[0013] Various embodiments are directed to a computer program product for garbage collection in a storage system, wherein a virtual address space is mapped to a physical address space, the virtual address space is addressed in extents, and the storage system has one or more processors, a plurality of storage devices, and a cache memory.

[0014] Various embodiments relate to a storage system having a virtual address space mapped to a physical address space, the virtual address space being addressed in disk extents, the storage system having one or more processors, multiple storage devices, and cache memory, the storage system including: a storage allocator and a garbage collector.

[0015] Various embodiments can protect a data storage system from data loss in the event of a cache failure with respect to garbage collection. Various embodiments provide a garbage collection algorithm that coordinates cache flush operations with respect to garbage collected data. Garbage collection is performed such that old data (i.e., live data stored in cache flush blocks) is not discarded until a storage allocator determines that any live data being moved from the garbage collected blocks has successfully passed through cache flush to its new physical memory location and has therefore safely reached and been stored in the target block for the garbage collected live data.

[0016] Note that although various embodiments have been designed to operate successfully in storage systems that use compression, embodiments can also be used in storage systems that do not use compression. Implementations of embodiments can be used to write new data to new locations and rely on any data reduction by garbage collection. For example, even if an overwrite to the same location would have worked, uncompressed data can be written as suggested.

[0017] In some embodiments, the release of physical address space following a cache flush of a destination disk area may be controlled by assigning a sequence number to each destination disk area, each sequence number allowing a lookup of a source disk area that has completed its garbage collection by moving data into that destination disk area, the sequence number of the oldest destination disk area that has not completed flushing being stored as a low-watermark sequence number, and the sequence number of the destination disk area currently assigned for garbage collection from the source disk area being stored as a high-watermark sequence number, wherein the low-watermark sequence number is incremented upon completion of flushing the oldest destination disk area from the cache memory, and the high-watermark sequence number is incremented upon selection of another destination disk area for garbage collection. If it is determined that the available virtual address space has become scarce, this may be managed by suspending the movement of valid data from the source disk area to the destination disk area; and releasing the physical address space mapped to the virtual address space of the destination disk area having a sequence number between the low-watermark value and the high-watermark value as available for writing.

[0018] In order to recover from, for example, spontaneous loss or corruption of cached contents, it is beneficial to maintain a log that stores recovery information for each sequence number between a low-watermark sequence number and a high-watermark sequence number, the recovery information including, for each sequence number, a mapping to a source disk area that had its garbage collection completed by moving data to a destination disk area associated with that sequence number. In the event that cached contents are lost during garbage collection, the recovery information can be used to reconstruct a forward lookup metadata structure that links the virtual address space to the physical address space of the source disk area identified in the recovery information.

[0019] The method and storage system are particularly suitable for, but not limited to, use in conjunction with an operating system in which each write is performed to a new extent. The method and storage system are particularly suitable for, but not limited to, use in conjunction with an operating system in which data is stored in compressed form.

[0020] In summary, various embodiments provide a garbage collection method for a virtualized storage system whose virtual address space is addressed in blocks called extents. Old extents are garbage collected by transferring their still valid data to new extents called destination extents. The garbage collected extents can then be released for reuse for new writes. To account for the possibility of cache misses while garbage collected data is still in the process of being written to physical storage, release of the garbage collected extents is initially blocked following their garbage collection. After the destination extent receiving the garbage collected data is full, a cache purge for that destination extent is initiated. Then, upon completion of the cache purge, the storage space of the garbage collected extents associated with the destination extent is released. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present invention will now be further described, by way of example only, with reference to exemplary embodiments shown in the accompanying drawings.

[0022] Figure 1 A computer system environment with a mass storage device is shown.

[0023] Figure 2 is a block diagram showing the hardware structure of the data storage system.

[0024] Figure 3A and 3B is a flow chart illustrating steps in a method according to the present disclosure.

[0025] Figures 4A to 4D is a schematic block diagram illustrating an example process of garbage collection according to the method of the present disclosure.

[0026] Figure 5 A cloud computing environment according to an embodiment of the present disclosure is depicted.

[0027] Figure 6 Abstract model layers according to an embodiment of the present disclosure are depicted.

[0028] Figure 7 is a schematic diagram of a server connected to a storage system according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] In the following detailed description, for purposes of explanation rather than limitation, specific details are set forth in order to provide a better understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be implemented in other embodiments that depart from these specific details.

[0030] As mentioned above, a popular strategy for performing writes in data storage systems is to always write new data ranges in the data domain. The advantage of this strategy is that RAID (Redundant Array of Independent Disks) arrays can be updated without performing any reads from the disks. However, the result of always performing writes to new data ranges is that a large amount of memory space is allocated, which must then be reclaimed through garbage collection. In practice, if data compression is used (which is an option in some operating systems such as IBM z / OS), the size of the writes will inevitably vary because the size will depend on the compressibility of the data. For example, one write may take up 8K of space, while another write only takes up 1K of space. Therefore, it is impossible to always overwrite data that is in place because there is no guarantee that the data being overwritten will fit in the old memory location when compression is used, so writes must always be performed to new data ranges.

[0031] Garbage collection reclaims old data ranges that have become dominated by stale data due to overwriting, and therefore contain only a sparse amount of active data. Garbage collection proceeds by reclaiming the remaining active data and writing it to new data ranges in contiguous blocks. When data is overwritten, it is said to be invalid. Garbage collection will take the area with invalid data on the data domain, move the active data out of the area and write it to a new location on the data domain; in the process, forward lookup metadata is updated. Forward lookup metadata can be implemented as a tree, the most common being a b-tree. The forward B-tree structure maps virtual memory addresses to physical memory addresses in the virtual storage system. Reverse lookup metadata describes which volumes reference a given range of the physical domain, and therefore records what data sub-ranges are allocated on the physical domain and what data sub-ranges are not allocated. Therefore, the garbage collection algorithm requires a reverse lookup structure.

[0032] Maintain a log that can be used to rebuild the forward lookup metadata structure in the event of a cache failure. Cache failures typically result in the loss of several gigabytes of active data. Logging ensures that every update to the forward lookup metadata is recorded in a sequential log. The log can be replayed to rebuild the forward lookup metadata. Integrating periodic replication (sometimes called snapshots) of the forward lookup metadata into the scheme eliminates the need for a potentially ever-growing log size because the log then only needs to track forward lookup updates since the last snapshot. In the case where the forward lookup metadata has a tree structure such as a B-tree, the periodic replication is sometimes called a tree snapshot. Note that the data referenced by the log itself is typically not logged because doing so would consume too much write bandwidth. The method of logging forward lookup metadata (e.g., B-tree updates) requires much less bandwidth. In different embodiments, logging and updating of the lookup structure can be performed by various modules or components. In various embodiments, logging and updating of the lookup structure can be performed by the storage allocator of the garbage collector.

[0033] A typical "write" will do the following: an input-output (IO) will be received for a given volume, with an address, size, and some data. The storage allocator will allocate a storage location on the physical domain for that volume. The IO path will then write to that location on the physical domain. After the write is complete, the forward and reverse lookup structures are updated, and the IO is completed. As part of the forward lookup update, the log is also updated.

[0034] A typical "read" will check the forward lookup structure to identify where the data is located on the data field. The data field will then be read and the data there will be returned to the user.

[0035] In the event of a system failure, cache contents may be lost: If the cache is present beneath a component that implements data reduction techniques, data in flight may be lost. (Data in flight is any data that has not yet been fully written to the media, and therefore may be lost if the cache is discarded.) This is a common failure mode in storage systems and is acceptable—or at least expected—to a certain extent. This is the performance tradeoff that arises when using this cache.

[0036] In storage systems or thick volumes with fixed physical domain locations for updates, cache misses can be tolerated because the result is simply returning the old data if the update was pending in the cache at the point of failure. However, for data reduction volumes, it may not be possible to consistently write to the same location during a rewrite, which means that data that was garbage collected at the time of the failure may also be lost, so this portion of the old data is not returned. In a file system, returning stale data is generally preferred to returning a media error (i.e., data loss).

[0037] Figure 1 An exemplary computer system 10 is shown, comprising a central processing unit (CPU) 12 connected to a mass storage device(s) 14 and a memory device 16. The mass storage device(s) may include hard disk drive (HDD) devices, which may be configured in a redundant array of independent disks (RAID). Garbage collection operations may be performed on the device(s) 14 located in the system 10 or elsewhere. The memory device 16 may include a host of memory devices (e.g., RAM, ROM, flash memory, etc.), such as an electrically erasable programmable read-only memory (EEPROM) or related devices. The memory device 16 and the mass storage device 14 are connected to the CPU 12 via a signal-carrying medium. In addition, the CPU 12 is connected to a communication network 20 via a communication port 18, which has a plurality of attached computer systems 22 and 24. The computer system 10 may include one or more processor devices (e.g., the CPU 12) and attached memory devices 16 for each individual component of the computer system 10 to perform and complete garbage collection and other operations, as described herein.

[0038] Figure 2 2 is an exemplary block diagram 200 illustrating the hardware structure of a data storage system in a computer system for implementing an embodiment of the present invention. Each of the host computers 210, 220, and 225 functions as a central processing unit for performing data processing as part of the data storage system 200. The hosts (physical or virtual devices) 210, 220, and 225 may be one or more new physical devices or logical devices for implementing the purpose of the present invention in the data storage system 200. In one embodiment, by way of example only, the data storage system 200 may be implemented as System Storage TM V9000 TM . The network connection 260 can be a Fibre Channel fabric, a Fibre Channel point-to-point link, a Fibre Channel over an Ethernet fabric or point-to-point link, a FICON or ESCON I / O interface, any other I / O interface type, a wireless network, a wired network, a LAN, a WAN, heterogeneous, homogeneous, public (i.e., the Internet), private, or any combination thereof. The hosts 210, 220, and 225 can be local or distributed between one or more locations and can be equipped with any type of fabric (or fabric channel) or network adapter 260 to the storage controller 240, such as a Fibre Channel, FICON, ESCON, Ethernet, fiber, wireless, or coaxial adapter. The data storage system 200 is accordingly equipped with the appropriate fabric or network adapter 260 for communication. Figure 2 The data storage system 200 described in FIG. 2 includes a storage controller 240 and a memory 230 .

[0039] exist Figure 2 The storage controller 240 is shown as a single processing unit including a microprocessor 242, a system memory 243, and a non-volatile storage device ("NVS") 216. However, it is noted that the storage controller 240 may also include multiple processing units, each having its own processor complex and system memory, and interconnected by a dedicated network within the data storage system 200. The storage device 230 may include one or more storage devices, such as storage arrays, which are connected to the storage controller 240 via a storage network.

[0040] In some embodiments, the devices included in the storage device 230 may be connected in a loop architecture. The storage controller 240 manages the storage device 230 and facilitates the processing of write and read requests to the storage device 230. The system memory 243 of the storage controller 240 stores operating software 250, program instructions and data that the processor 242 can access to perform functions and method steps associated with managing the storage device 230, including garbage collection. Figure 2 As shown, the system memory 243 includes an internal memory cache 245 (or alternatively, communicates with an external cache), which is a cache for the storage device 230. The cache memory is used to buffer write data for corresponding write requests and read data for corresponding read requests. In one embodiment, the cache 245 is allocated in a device external to the system memory 243, but is still accessible to the microprocessor 242 and can be used to provide additional security against data loss.

[0041] In some embodiments, cache 245 is implemented with volatile memory and non-volatile memory and is accessed via a local bus ( Figure 2 The NVS 216 is coupled to the microprocessor 242 (not shown) to enhance the performance of the data storage system 200. The NVS 216 included in the data storage controller 240 is accessible by the microprocessor 242 and is used to provide additional support for operations including garbage collection. The NVS 216 may be referred to as a persistent cache because it may be implemented with non-volatile memory that does not require power to retain its data. The NVS 216 may be integrated with the cache 245. In some embodiments, a backup power source (such as a battery) Figure 2 245) provides sufficient power to the NVS 216 to maintain the data stored therein in the event of a power outage in the data storage system 200. In some embodiments, the capacity of the NVS 216 is less than or equal to the total capacity of the cache 245.

[0042] Storage device 230 may physically include one or more storage devices, such as storage arrays. A storage array is a logical combination of individual storage devices (such as hard disks). In some embodiments, storage device 230 includes a JBOD (Junction of a Cluster of Disks) array or a RAID (Redundant Array of Independent Disks) array. A collection of physical storage arrays may be further combined to form ranks, which separate physical storage from logical configuration. Storage space within a rank may be allocated to logical volumes, which define the storage locations specified in write / read requests.

[0043] like Figure 2 The storage system shown can include logical volumes (or simply "volumes"), which can have different types of allocations. Storage 230a, 230b, and 230n are shown as tiers in the data storage system 200 and are referred to herein as tier 230a, tier 230b, and tier 230n. The tiers can be local to the data storage system 200 or can be located at physically remote locations. In other words, a local storage controller can connect to a remote storage controller and manage storage at the remote location. Tier 230a is shown as being configured with two full volumes 234 and 236 and one partial volume 232a. Tier 230b is shown as having another partial volume 232b. Thus, volume 232 is allocated across tiers 230a and 230b. Tier 230n is shown as being fully allocated to volume 238, i.e., tier 230n refers to the entire physical storage of volume 238. From the above examples, it will be understood that tiers can be configured to include one or more partial volumes and / or entire volumes.

[0044] The storage controller 240 includes a garbage collection module 255 to assist in garbage collection in the journaled file system. The garbage collection module 255 operates in conjunction with components of the storage controller 240, the hosts 210, 220, 225, and the storage device 230. The garbage collection module 255 may be located in the cache 245 or in other components of the storage controller 240.

[0045] The storage controller 240 includes a control switch 241 (for controlling the Fibre Channel protocol to the host computers 210, 220, and 225), a microprocessor 242 (for controlling all storage controllers 240), a non-volatile control memory 243 (for storing a microprogram (operating software) 250 for controlling the operation of the storage controller 240), a cache 245 (for temporarily storing (buffering) data), and a buffer 244 (for assisting the cache 245 in reading and writing data), a control switch 241 (for controlling the protocol for data transmitted to or from the storage device 230), and a garbage collection module 255 (in which information can be set). Multiple buffers 244 can be implemented to facilitate garbage collection in the journaling file system.

[0046] The host computer or one or more physical or virtual devices 210, 220, 225 and the storage controller 240 are connected through a network adapter (which can be a fiber channel) 260 as an interface, that is, via a switch called a "fabric". The microprocessor 242 can control the memory 243 to store command information from the host device (physical or virtual) 210 and information for identifying the host device (physical or virtual) 210. The control switch 241, buffer 244, cache 245, operating software 250, microprocessor 242, memory 243, NVS 216 and garbage collection module 255 communicate with each other. Some or all components such as the operating software 245 can be included in the memory 243 for performing garbage collection in the journaling file system. Each component within the device shown can be linked together and can communicate with each other.

[0047] Figure 7 A server 710 is shown connected to a storage system 712, in which the principles of the present invention may be implemented in various embodiments. Server 710 performs read and write operations with respect to storage system 712 via an interface (e.g., using a standard such as SCSI (Small Computer System Interface)). Storage system 712 has multiple connected physical components that provide processing and storage functions. Primary long-term storage functions are provided by a set of physical storage devices 714 (which preferably include a set of disks), which are divided into logically allocated areas 716. Additional storage is also provided within storage system 712 via a write cache 718, which is used locally by the processing components of storage system 712.

[0048] From the perspective of an external server 710, the storage system 712 presents one or more virtual disks 720 (vdisks) that logically present stored data to the external server 710. Data presented as being present on a single vdisk 720 to the server 710 may actually be stored on different disks 714 within the actual physical storage domain 714. The mapping between virtual disks 720 and physical disks 714 is managed by two components within the storage system 712: a forward lookup structure 722 and a reverse lookup structure 724. The forward lookup structure 722 maps one or more addresses in the virtual disks 720 to the actual physical locations in the disks 714 where the data is stored. The reverse lookup structure 724 maps physical locations within the disks 714 back to addresses within one or more of the virtual disks 720.

[0049] When a read arrives at virtual disk 720 from server 710, virtual disk 720 communicates with forward lookup structure 722 to obtain the physical address of the data and then reads the desired data from the address within physical domain 714. In the case of a read, no changes need to be made to either forward lookup structure 722 or reverse lookup structure 724.

[0050] The behavior is more complex when writes arrive from server 710 to virtual disk 720. When new data is written to disk 714, forward lookup structure 722 must be updated to connect the address of the new data in virtual disk 720 with the physical location where the data is actually stored on disk 714. In this case, both forward lookup structure 722 and reverse lookup structure 724 must be updated to reflect the connection between the data presented by virtual disk 720 to server 710 and the actual physical location where the data is stored on disk 714.

[0051] The storage system 712 also includes two additional components: a storage allocator 726 and a garbage collector 728. The storage allocator 726 performs a variety of functions, primarily allocating active blocks from active regions 716 within the physical domain 714 (which communicates with the virtual disk 720) and maintaining a free list for the allocated data, as described in more detail below. When new data is to be written to the storage system 712, a forward lookup structure 722 writes to a location determined by the allocated block location. The top-level storage allocator 726 has a set of "active" regions 716 that are tracked at any given time. A finite number of these regions 716 can be tracked. For example, in an exabyte physical domain 714 with a region size of a gigabyte (for example), this would result in tracking a billion regions. Even if the region entries within the storage allocator 26 only took up 4 bytes (i.e., to track how many blocks were available in the regions 716), this would still consume 4 GB worth of memory, which is memory better used as a cache. Thus, a set of active regions 16 is maintained until N regions 16 are large (where N is the maximum value that the cache 18 can handle). When all storage in an active region 716 is exhausted, the entire region 716 is removed from the set of active regions 716, and the memory used to track the region 716 can be reclaimed and, if applicable, garbage collected by the garbage collector 728. When all N regions 716 are active, no additional regions 716 can be allocated, and this means that there are no free lists (lists of unallocated blocks of memory) to accept additional host blocks. The garbage collector 728 essentially reclaims regions 716 with limited valid data by overwriting other valid data to new regions 176, which releases these reclaimed regions 716 back to the storage allocator 726. The garbage collector 728 (or garbage collection module) is connected to the reverse lookup structure 724 for performing garbage collection.

[0052] The storage system 712 is presented to the server 710 as thinly provisioned (also known as space efficient), where the underlying storage can be much smaller than the storage presented to the host (server 710). This is achieved through metadata structures that map virtual domain writes to the physical domain, as well as through compression and deduplication. Implementations that utilize compression must implement a mechanism for space recovery, known as garbage collection, because there is no guarantee that any two writes to the same virtual address will utilize the same amount of physical storage. Historically, disks 714 have been left with many small areas of free space, and it has been desirable to consolidate these areas by moving writes in the physical domain (and updating their mappings in the virtual domain).

[0053] Now let's describe the role of the log. The log tracks updates that enter the b-tree. The b-tree stores mappings between virtual and physical addresses. The log's purpose is to track changes to these mappings in the event of errors during updates. The b-tree can then be restored using the recovery information in the log. This prevents corruption of the mapping between the virtual and physical domains due to cache loss or other errors.

[0054] In this case, the rewrite operation, the steps associated with logging, are: writing the new data to the new location; updating the b-tree to record the physical address of the new location; and marking the old physical data as invalid (stale). Garbage collection will then have to run and move any non-invalid data (i.e., still valid data) mixed in with the invalid data. Typically, the valid data in a particular virtual memory block will only constitute a fairly small portion of the total, such as 10% or less. Garbage collection will move the still-valid data (which is most likely cold (i.e., on main memory, physical storage, and no longer in cache memory)), and the action of garbage collection will cause this cold data to become hot, i.e., in transit in cache memory, and therefore at risk of being lost in the event of a failure.

[0055] Various embodiments provide a garbage collection method for a virtualized storage system in which a virtual address space is mapped to a physical address space. The method can be implemented by modifying the system's storage allocator. The method can be used for storage systems that store data in compressed form, such as IBM z / OS, and can also be used for uncompressed storage systems. The method is particularly contemplated for use with storage systems that are always writing to new virtual memory space to reduce reads and therefore consume a large amount of virtual memory space and require continuous garbage collection. According to various embodiments, the storage allocator tracks virtual memory for writes in blocks, where each block is a range of virtual memory addresses. These blocks are called "extents."

[0056] In various embodiments, the garbage collection method proceeds as follows: A storage allocator selects an extent to receive garbage collected data, which is called the destination or target extent.

[0057] The storage allocator selects the extents to be garbage collected (called source extents), and the virtual addresses of the source extents are marked as containing valid data or invalid data. As mentioned above, the amount of valid data may be quite small relative to the size of the source extents, that is, much smaller than the amount of invalid data. In other words, each destination extent may have enough space to receive all the valid data from several source extents; perhaps 5 to 10 is a typical number.

[0058] The storage allocator, or in some embodiments, the garbage collector 728 (or garbage collection module 255), moves or copies valid data in the source disk area to the destination disk area via the cache memory, and then repeatedly selects the second, third, and so on source disk areas in turn for garbage collection, each time moving the valid data to the destination disk area via the cache memory. This continues until the destination disk area is full. The garbage collector 728 (or garbage collection module 255) can determine when the destination disk area is full. When the destination disk area becomes full, the remaining data that is still to be moved or copied from the source disk area and is being garbage collected can be rolled, that is, copied to the next allocated destination disk area. The entire source disk area data from a given source disk area does not need to go into one destination disk area. It can be divided into two; it only needs to be marked according to the last one, because various embodiments provide sequential flushing, so it can be guaranteed that both destination disk areas will be cleared subsequently.

[0059] When the current destination disk for garbage collection is full, the storage allocator or garbage collector selects another disk to become the next destination disk, and thus allows garbage collection to continue. The process is then repeated by filling the next destination disk with valid data for garbage collection, and so on.

[0060] Asynchronously with the continued filling of successive destination disks and the clearing of still valid data from a much larger number of source disks, each complete destination disk is cleared from the cache in turn. Clearing of each destination disk from the cache memory in the order in which they were allocated and filled is initiated only after each destination disk becomes full. Clearing and garbage collection transfers are controlled independently, so the amount of time spent clearing each destination disk may be slower or faster relative to the speed of garbage collection. Due to the asynchrony between clearing and garbage collection transfers between source and destination disks, the virtual address space of the garbage collected source disk is not immediately available for new writes, but is temporarily reserved. After the clearing of each destination disk is completed, a release is performed, where "release" means making available for writes to the physical address space mapped to the virtual address space of the source disk, and the valid data of the source disk is completely cleared from the cache memory by clearing that particular destination disk. Therefore, although the cache clearing and subsequent release of old addresses are not performed synchronously with the garbage collection from the source disk to the destination disk, these activities are coordinated.

[0061] Figure 3A The process flow of a garbage collection activity is shown. In step S1, a destination disk area is selected to receive garbage collection data. In step S2, a source disk area is selected for garbage collection. Steps S1 and S2 may be performed by a storage allocator. In step S3, valid data in the source disk area is identified, and in step S4, the valid data is moved or copied to the destination disk area. Steps S4 and S5 may be performed by the storage allocator or by the garbage collector. In step S5, if the destination disk area is full (as determined by the storage allocator or by the garbage collector), the process flow returns to step S1 to select a new destination disk area to continue garbage collection, and in step S2, additional data from an existing source disk area or a new source disk area will be selected. The now full destination disk area is as shown in FIG. Figure 3B The shown caches are candidates for clearing.

[0062] Figure 3B The process flow for cache clearing and freeing an extent that has been garbage collected (i.e., a source extent) is shown. In step F1, a complete destination extent is selected for cache clearing. The complete destination extent is selected for cache clearing by the garbage collector. In step F2, a cache clear can be initiated by the garbage collector. After the cache clear is complete, as determined by the garbage collector in step F3, the memory space mapped to the source extent that has been garbage collected into the just cleared destination extent can be released by the storage allocator in step F4 for new writes.

[0063] In more detail, the method can be implemented so that each write to disk has a metadata header that documents what volume it originally belonged to and the forward lookup logical block address (LBA). When all metadata updates are completed, the reverse lookup structure (e.g., b-tree) associated with a particular disk area is updated and cleared to main memory (from cache to disk) via cache memory. When garbage collection is completed, the garbage collected disk area has its reverse lookup metadata updated to the document that it has been garbage collected, but the garbage collected disk area is not processed immediately, that is, it is not immediately available for new writes, but it is temporarily retained and therefore remains available in the event that the cache contents are lost. The reverse lookup metadata of the disk area is discarded only when the garbage collected disk area is subsequently reused or discarded.

[0064] Extents can be used simultaneously by more than one implementation forward lookup structure (e.g., b-tree). Cache flushing is triggered after all metadata updates have been completed for an extent. Since writes are always written to "fresh" locations (either to newly allocated storage or to previously garbage collected extents), the cache effectively serves only as a temporary buffer for full-span writes.

[0065] The storage allocator distinguishes between the current extents that are used to receive new writes inbound to the system and the current extents that are used internally to receive garbage collected data from other extents. The storage allocator keeps track of the set of extents that are currently active in garbage collection by using a pair of sequence numbers. (In systems that support multiple storage nodes, a separate sequence number can be used for each node.)

[0066] When garbage collection is performed on a disk area, instead of allowing the old disk area to be reused immediately after it is garbage collected, the old disk area is temporarily retained on it, that is, temporarily delayed, marking it as a new disk area available for writing. Since active data from a disk area that has been garbage collected may have been assigned to be moved to multiple destination disk areas, and it is expensive to track each of these disk areas individually, various embodiments track which disk areas are currently used for writing through a pair of sequence numbers, which are referred to as low watermark sequence numbers and high watermark sequence numbers in this article. The use of low and high watermark sequence numbers simplifies the control of the release of physical address space after the cache of the destination disk area is cleared. The storage controller assigns a unique sequence number to each destination disk area. Each sequence number allows the source disk area that has completed garbage collection by moving data to the destination disk area to be found. The sequence number of the oldest destination disk area that has not completed the clearing is stored as the low watermark sequence number. The sequence number of the destination disk area currently assigned for garbage collection from the source disk area is stored as the high watermark sequence number. The low watermark sequence number value is incremented after the oldest destination extent is purged from the cache memory, and the high watermark sequence number value is incremented after another destination extent is selected for garbage collection. Since the speed of purging is variable and may be slower than the filling of the destination extents at some time periods and faster at other time periods, the difference between the low watermark value and the high watermark value will increase and decrease over time.

[0067] Since destination extents are purged in order of increasing sequence numbers, the low watermark sequence number always corresponds to the oldest destination extent for which purging is incomplete. Thus, the range of extents with indices between the low and high watermark sequence numbers indicates those destination extents that are potentially at risk of cache content loss or other cache errors (and therefore indicates garbage collected extents for which they have already received garbage collected data). Only when a destination extent is known with certainty to have been purged to disk can the garbage collected extents that depend on it be safely released for new writes.

[0068] The presence of low-watermark and high-watermark sequence numbers can also simplify what needs to be stored in the log to prevent cache errors. The storage controller can limit the recovery information stored in the log to memory addresses linked to sequence numbers between the low-watermark and high-watermark values. The recovery information for each such sequence number includes a mapping to a source extent, which is garbage collected by moving data to the destination extent associated with that sequence number. In the event that cache contents are lost during garbage collection, the recovery information is used to reconstruct the forward lookup metadata structure, which links the virtual address space to the physical address space of the source extent identified in the recovery information. That is, the log can attempt to restore the forward lookup structure through a replay method. This replay method reads the log entry indicating the physical address of the destination extent, then reads the destination extent in the physical domain to determine whether the location pointed to by the log entry has the correct metadata header for the volume it is attempting to restore. If a mismatch is found between the log and data domains, log replay continues to a later log entry, and the recovered address is left as a media error, allowing the later log entry to find more valid data. This replay method attempts to find the last reference that has not been overwritten. Further details of this replay method are disclosed in commonly owned, co-pending U.S. patent application Ser. No. 16 / 548,474, filed on August 22, 2019, entitled "Data Validation During Data Recovery in a Log-Structured Array Storage System," the entire contents of which are incorporated herein by reference. When it is identified that a reference to a garbage-collected extent has been recovered, the extent in question must be treated as if garbage collection has not yet been successful and, therefore, as requiring a second round of garbage collection. Because the reverse lookup metadata may have marked the recovered reference as invalid, it is necessary to mark the extent as subject to garbage collection without using the reverse lookup structure. This is achieved by utilizing the header data associated with each write. Garbage collection will inject all volume writes it can identify on the data disks from the header into the IO path. The IO path will reject writes that originally originated from locations that do not match the forward lookup structure. This is achieved for both garbage collection with and without the reverse lookup structure, as it eliminates the requirement that the reverse lookup structure be completely consistent with the forward lookup structure. Because we have identified and prevented reuse of extents that were garbage collected before the purge was complete, the replay method will always find data that belonged to extents that were garbage collected in the event of a cache miss.

[0069] As a result, the proposed method consumes more memory space than conventional methods because it retains extents longer than methods that immediately reuse garbage-collected extents. Therefore, it's possible that using the proposed method will lead to a shortage of virtual memory space, bearing in mind that a particular user, business entity, or application will typically be allocated only a fixed amount of virtual memory space. In particular, if purging slows down for whatever reason, the difference between the low and high watermark values ​​can become high, meaning that a significant amount of storage space may be wasted in garbage collection. Therefore, if the amount of free virtual memory decreases below a certain threshold, such as 10% or 5% of the total available virtual memory, it may be beneficial to halt garbage collection activity according to the proposed method. This method will allow virtual memory space allocated to garbage-collected destination extents for those destination extents whose source extents have not yet been freed to be freed and made available for new writes. If it is determined that available virtual address space has become scarce, the storage allocator suspends garbage collection by halting the movement of valid data from source to destination extents. It can then release the physical address space mapped to the virtual address space of the destination disk areas as available for writes, where the sequence numbers are between the low watermark value and the high watermark value. This release may not actually be instantaneous, as it will involve first notifying all parts of the storage allocator to stop using these destination disk areas. After all storage devices associated with these destination disk areas have been reported as fully used or have been discarded, these destination disk areas can be released for new writes. Another option to deal with the same problem is to set a maximum limit (cap) on the difference between the low watermark value and the high watermark value, so there is a maximum number of destination disk areas that can be bundled with garbage collection. When the cap is hit, this will stop garbage collection until the low watermark sequence number is incremented, that is, until the current cache clear is completed.

[0070] Figures 4A to 4D is a schematic block diagram illustrating an exemplary process of garbage collection according to the proposed method. Figures 4A to 4D The time sequence is shown schematically. Initially, the virtual memory uses three example extents: Ext1, Ext2, Ext3, which are transferred to the physical memory via the cache. Ext1 (Ext1) contains a mix of cold data and stale (still valid) data to be garbage collected. Ext2 (Ext2) contains cold static data. Ext3 (Ext3) is the extent currently used for new writes. Ext1 is then identified as a candidate for garbage collection based on its relatively small proportion of still valid data. The garbage collection process reads the extents and selects the data to keep (401). As Figure 4B As shown schematically in , stale data from disk zone 1 is marked as being discarded, while still valid "active" data from disk zone 1 is written to disk zone 3. Figure 4CIt is shown that even after garbage collection from extent 1 to extent 3 is completed, the data is still retained in extent 1, while the garbage collected data may still be transferred to physical storage via the cache. Figure 4D It then shows how extent 1 can be discarded after the cache has been flushed to physical storage on extent 3.

[0071] It will be clear to one of ordinary skill in the art that all or part of the logical process steps of the preferred embodiment may alternatively be implemented in a logic device or multiple logic devices, which include logic elements arranged to perform the logical process steps of the method, and the logic elements may include hardware components, firmware components, or a combination thereof.

[0072] It will also be clear to those skilled in the art that all or part of the logic components of the preferred embodiments may alternatively be implemented in a logic device comprising logic elements to perform the steps of the method, and such logic elements may include components such as logic gates in, for example, a programmable logic array or an application-specific integrated circuit. Such a logic arrangement may also be implemented as an enabling element for temporarily or permanently establishing a logic structure in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored and transmitted using a fixed or transportable carrier medium.

[0073] In another alternative embodiment, the present invention may be implemented in the form of a computer-implemented method of deploying a service, the method comprising the steps of deploying a computer program which, when deployed into and executed on a computer infrastructure, is operable to cause a computing device to perform all the steps of the method.

[0074] It will be appreciated that the methods and components of the preferred embodiments may alternatively be implemented in whole or in part in a parallel computing system comprising two or more processors for executing parallel software.

[0075] Another embodiment of the present disclosure is a computer program product defined in accordance with the systems and methods. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform various aspects of the present invention.

[0076] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device.

[0077] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform various aspects of the present invention.

[0078] A computer-readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. A computer-readable storage medium can 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

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

[0080] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can 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 can be connected to an external computer (such as, using an Internet service provider through the Internet). In some embodiments, in order to perform various aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can execute the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions.

[0081] Various 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 present disclosure. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0082] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct the computer, programmable data processing device and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

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

[0084] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing the specified logical function. In some alternative embodiments, the functions noted in the frame may not occur in the order noted in the figure. For example, the two frames shown in succession can actually be implemented as a step, simultaneously, substantially simultaneously, in a manner that overlaps part or all of the time, or these frames can sometimes be performed in reverse order, depending on the functions involved. It will also be noted that each frame of the block diagram and / or flow chart illustration and the combination of the frames in the block diagram and / or flow chart illustration can be implemented by a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0085] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings set forth herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0086] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0087] Features are as follows:

[0088] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed without manual interaction with the service provider.

[0089] Wide Area Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0090] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. This is location-independent in the sense that consumers typically do not control or know the exact location of the provided resources, but are able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0091] Rapid elasticity: In some cases, the ability to scale out quickly and in quickly can be provided quickly and elastically. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0092] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and consumer of the utilized service.

[0093] The service model is as follows:

[0094] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications are accessed from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0095] Platform as a Service (PaaS): The capability provided to consumers is to deploy consumer-created or acquired applications onto cloud infrastructure. These applications are built using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and possibly the configuration of the application hosting environment.

[0096] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but do have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0097] The deployment model is as follows:

[0098] Private cloud: The cloud infrastructure is operated solely for the organization. It can be managed by the organization or a third party and can exist inside or outside the building.

[0099] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0100] Public cloud: Cloud infrastructure is available to the general public or large industrial groups and is owned by the organization that sells cloud services.

[0101] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a unique entity but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0102] The cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure consisting of a network of interconnected nodes.

[0103] Now refer to Figure 5 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 5 The types of computing devices 54A-N shown in FIGURE 5 are intended for illustration only, and computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and / or network-addressable connection (eg, using a web browser).

[0104] The additional components according to the embodiments of the present disclosure can be installed as follows Figure 5 One of cloud computing nodes 10 may host a website from which the add-on may be downloaded upon request to a third-party computing device, such as any of computing devices 54A, 54B, and 54C. The request causes the add-on to be sent from node 10 to computing devices 54A / 54B / 54C via a network connection, where the add-on is sent along with an installation program for integrating the add-on with the web browser already present on the computing device.

[0105] Now refer to Figure 6 , showing the cloud computing environment 50 ( Figure 5 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 6The components, layers, and functions shown in the are intended to be illustrative only, and the embodiments of the present disclosure are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0106] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: host 61, RISC (Reduced Instruction Set Computer) architecture based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0107] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 , virtual storage 72 , virtual networks 73 (including virtual private networks), virtual applications and operating systems 74 , and virtual clients 75 .

[0108] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides for dynamic procurement of computing and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides for cost tracking when utilizing resources in a cloud computing environment, as well as billing or invoicing for the consumption of those resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. A user portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides for allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides for pre-scheduling and procurement of cloud computing resources, where future demand is anticipated based on the SLA.

[0109] The workload layer 90 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91, software lifecycle management 92, virtual classroom education delivery 93, data analysis processing 94, transaction processing 95, and a storage allocator 96 with garbage collection management as described above according to an embodiment of the present disclosure.

[0110] It will be apparent to those skilled in the art that many improvements and modifications can be made to the foregoing exemplary embodiments without departing from the scope of the present disclosure.

Claims

1. A method of garbage collection in a storage system, wherein a virtual address space is mapped to a physical address space, the virtual address space is addressed in a disk area, and the storage system has one or more processors, a plurality of storage devices and a cache memory, the method comprising: selecting a first destination extent as a current destination extent for receiving garbage collected data; Selecting a first source extent as a current source extent to be garbage collected, the current source extent including one or more portions of valid data; determining whether a destination extent selected as the current destination extent for receiving garbage collected data is full; determining whether a source extent selected as the current source extent for garbage collection includes one or more portions of valid data that have not been copied to a destination extent; In response to determining that the current destination disk area for receiving garbage collected data is not full and determining that the current source disk area for garbage collection includes one or more portions of valid data that are not copied to the destination disk area, copying one of the portions of valid data that are not copied to the destination disk area from the current source disk area to the current destination disk area via the cache memory; In response to determining that the current destination disk area for receiving garbage collected data is full, flushing the valid data copied to the current destination disk area via the cache memory out of the cache memory; as well as After the valid data to be moved to the current destination disk area is cleared from the cache memory, the physical address space mapped to the virtual address space of one or more source disk areas in which all valid data is stored is released for writing, and all valid data is copied to the current destination disk area via the cache memory.

2. The method according to claim 1, further comprising: In response to determining that the current destination extent for receiving garbage collected data is full, a second destination extent is selected as the current destination extent for receiving garbage collected data.

3. The method according to claim 2, further comprising: In response to determining that the second destination disk area for receiving garbage collected data is full, clearing the valid data copied to the current destination disk area via the cache memory from the cache memory, Therein, valid data copied to the current destination disk area via the cache memory is cleared from the cache memory in the same order as the order in which the destination disk area is determined to be full.

4. The method of claim 1, wherein in response to determining that the current source disk area to be garbage collected does not include a portion of valid data that has not been copied to a destination disk area, a second source disk area is selected as the current source disk area to be garbage collected.

5. The method according to claim 1, further comprising: Controlling the release of physical address space after a cache flush of a destination extent by assigning a sequence number to each destination extent, each sequence number allowing a lookup of the source extent whose garbage collection was completed by copying data into the destination extent, storing the sequence number of the oldest destination extent for which no purge has been performed as the low-watermark sequence number, and The sequence number of the current destination extent allocated for garbage collection from the source extent is stored as a high-watermark sequence number, where The low-watermark sequence number is incremented upon completion of the purge of the oldest destination extent from the cache memory, and The high-watermark sequence number is incremented when another destination extent is selected for garbage collection.

6. The method according to claim 5, wherein: In response to determining that the available virtual address space is less than a threshold: suspending the copying of valid data from the source extent to the destination extent; and The physical address space of the virtual address space mapped to at least one destination disk area having a sequence number between the low watermark sequence number and the high watermark sequence number is released for use in writing.

7. The method according to claim 5, further comprising: A log is maintained storing recovery information of destination extents having sequence numbers between the low watermark sequence number and the high watermark sequence number, the recovery information comprising a mapping between source extents whose valid data are subject to garbage collection and corresponding destination extents.

8. The method according to claim 7, further comprising: In response to determining that cache contents were lost during garbage collection, the recovery information is used to reconstruct a forward lookup metadata structure that links a virtual address space to a physical address space of the source disk area identified in the recovery information.

9. A computer program product for garbage collection in a storage system, wherein a virtual address space is mapped to a physical address space, the virtual address space being addressed in extents, and the storage system having one or more processors, a plurality of storage devices, and a cache memory, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by a processor to cause the processor to: selecting a first destination extent as a current destination extent for receiving garbage collected data; Selecting a first source extent as a current source extent to be garbage collected, the current source extent including one or more portions of valid data; determining whether a destination extent selected as the current destination extent for receiving garbage collected data is full; determining whether a source extent selected as the current source extent for garbage collection includes one or more portions of valid data that have not been copied to a destination extent; In response to determining that the current destination disk area for receiving garbage collected data is not full and determining that the current source disk area for garbage collection includes one or more portions of valid data that are not copied to the destination disk area, copying one of the portions of valid data that are not copied to the destination disk area from the current source disk area to the current destination disk area via the cache memory; In response to determining that the current destination disk area for receiving garbage collected data is full, flushing the valid data copied to the current destination disk area via the cache memory out of the cache memory; as well as After the valid data to be moved to the current destination disk area is cleared from the cache memory, the physical address space mapped to the virtual address space of one or more source disk areas in which all valid data is stored is released for writing, and all valid data is copied to the current destination disk area via the cache memory.

10. The computer program product of claim 9, further comprising: In response to determining that the current destination extent for receiving garbage collected data is full, a second destination extent is selected as the current destination extent for receiving garbage collected data.

11. The computer program product of claim 10, further comprising: In response to determining that the second destination disk area for receiving garbage collected data is full, clearing the valid data copied to the current destination disk area via the cache memory from the cache memory, Therein, valid data copied to the current destination disk area via the cache memory is cleared from the cache memory in the same order as the order in which the destination disk area is determined to be full.

12. The computer program product of claim 9, wherein in response to determining that the current source extent to be garbage collected does not include a portion of valid data that has not been copied to a destination extent, a second source extent is selected as the current source extent to be garbage collected.

13. The computer program product of claim 9, further comprising: Controlling the release of physical address space after a cache flush of a destination extent by assigning a sequence number to each destination extent, each sequence number allowing a lookup of the source extent whose garbage collection was completed by copying data into the destination extent, storing the sequence number of the oldest destination extent for which no purge has been performed as the low-watermark sequence number, and The sequence number of the current destination extent allocated for garbage collection from the source extent is stored as a high-watermark sequence number, where The low-watermark sequence number is incremented upon completion of the purge of the oldest destination extent from the cache memory, and The high-watermark sequence number is incremented when another destination extent is selected for garbage collection.

14. The computer program product of claim 13, wherein: In response to determining that the available virtual address space is less than a threshold: Suspend the copying of valid data from the source disk area to the destination disk area; as well as The physical address space of the virtual address space mapped to at least one destination disk area having a sequence number between the low watermark sequence number and the high watermark sequence number is released for use in writing.

15. The computer program product of claim 13, further comprising: A log is maintained storing recovery information of destination extents having sequence numbers between the low watermark sequence number and the high watermark sequence number, the recovery information comprising a mapping between source extents whose valid data are subject to garbage collection and corresponding destination extents.

16. The computer program product of claim 15, further comprising: In response to determining that cache contents were lost during garbage collection, the recovery information is used to reconstruct a forward lookup metadata structure that links a virtual address space to a physical address space of the source disk area identified in the recovery information.

17. A storage system having a virtual address space mapped to a physical address space, the virtual address space being addressed in a disk area, the storage system having one or more processors, a plurality of storage devices, and a cache memory, the storage system comprising: a storage allocator for selecting a first target extent as a current target extent for receiving garbage collected data; The storage allocator is used to select a first source disk area as a current source disk area to be garbage collected, the current source disk area including one or more portions of valid data; a garbage collector for determining whether a destination extent selected as said current destination extent for receiving garbage collected data is full; The garbage collector is used to determine whether the source extent selected as the current source extent for garbage collection includes one or more portions of valid data that have not been copied to the destination extent; In response to determining that the current destination disk area for receiving garbage collected data is not full and determining that the current source disk area subject to garbage collection includes one or more portions of valid data that have not been copied to the destination disk area, the garbage collector is operable to copy one of the portions of valid data that have not been copied to the destination disk area from the current source disk area to the current destination disk area via the cache memory; In response to determining that the current destination disk area for receiving garbage collected data is full, the garbage collector clears the valid data copied to the current destination disk area via the cache memory out of the cache memory; as well as After the valid data to be moved to the current destination disk area is cleared from the cache memory, the storage allocator releases the physical address space of the virtual address space mapped to one or more source disk areas in which all valid data is stored as available for writing, and all valid data is copied to the current destination disk area via the cache memory.

18. The storage system according to claim 17, further comprising: In response to determining that the current destination extent for receiving garbage collected data is full, the storage allocator selects a second destination extent as the current destination extent for receiving garbage collected data.

19. The storage system according to claim 18, further comprising: In response to determining that the second destination disk area for receiving garbage collected data is full, the garbage collector clears the valid data copied to the current destination disk area via the cache memory from the cache memory, Therein, valid data copied to the current destination disk area via the cache memory is cleared from the cache memory in the same order as the order in which the destination disk area is determined to be full.

20. The storage system of claim 17, wherein in response to determining that the current source disk area for garbage collection does not include a portion of valid data that has not been copied to a destination disk area, the storage allocator selects a second source disk area as the current source disk area for garbage collection.

21. The storage system according to claim 17, further comprising: the storage allocator being for controlling the release of physical address space following a cache flush of a destination extent by assigning a sequence number to each destination extent, each sequence number allowing a lookup of the source extent whose garbage collection was completed by copying data into the destination extent, storing the sequence number of the oldest destination extent for which no purge has been performed as the low-watermark sequence number, and The sequence number of the current destination extent allocated for garbage collection from the source extent is stored as a high-watermark sequence number, where The low-watermark sequence number is incremented upon completion of the purge of the oldest destination extent from the cache memory, and The high-watermark sequence number is incremented when another destination extent is selected for garbage collection.

22. The storage system according to claim 21, wherein: In response to determining that the available virtual address space is less than a threshold: The storage allocator suspends copying of valid data from a source extent to a destination extent; and The storage allocator releases the physical address space of the virtual address space mapped to at least one destination disk area having a sequence number between the low watermark sequence number and the high watermark sequence number as available for writing.

23. The storage system according to claim 21, further comprising: The garbage collector maintains a log storing recovery information of destination disk areas having sequence numbers between the low watermark sequence number and the high watermark sequence number, the recovery information including a mapping between source disk areas whose valid data are subject to garbage collection and corresponding destination disk areas.

24. The storage system according to claim 23, further comprising: In response to determining that cache contents are lost during garbage collection, the garbage collector uses the recovery information to rebuild a forward lookup metadata structure that links a virtual address space to a physical address space of the source disk area identified in the recovery information.

Images