Technique for copying unallocated logical regions of thin logical units

A technique for use in managing data storage in a data storage system is disclosed. A first and second data storage commands (DSC) are received from a storage driver stack. Determining if the first DSC and the second DSC are both related aspects of a combined storage command and if so, establishing a pairing structure to pair the first DSC and the second DSC together. Fulfilling the combined storage command by fulfilling both the first DSC and the second DSC with reference to the pairing structure.

TECHNICAL FIELD

The present invention relates to data storage systems.

BACKGROUND OF THE INVENTION

Data storage systems (DSS) are integrated systems that allow persistent data storage to be presented to remote host devices in an efficient manner. A host may transmit data storage commands to the DSS for processing. A DSS may be configured as one or more storage processors attached to underlying persistent storage, each storage processor being configured to process data storage commands.

In order to reduce host and network overhead, certain operations may be offloaded to the DSS. For example, Windows-based Xcopy Lite and VMware® vSphere® Storage APIs—Array Integration (VAAI) XCOPY allow a host to instruct the DSS to transfer data from one location on the DSS to another location on the DSS without transferring the data to the host over the network.

SUMMARY OF THE INVENTION

A technique for use in managing data storage in a data storage system is disclosed. A first and second data storage commands (DSC) are received from a storage driver stack. Determining if the first DSC and the second DSC are both related aspects of a combined storage command and if so, establishing a pairing structure to pair the first DSC and the second DSC together. Fulfilling the combined storage command by fulfilling both the first DSC and the second DSC with reference to the pairing structure.

DETAILED DESCRIPTION

Embodiments are directed to techniques for allowing a mapping driver in a driver stack to be made aware of a relationship between related source and destination inter-driver calls so that it can pair them together and make integrated copy calls down to a physical storage driver at the bottom of the stack. This pairing may also be useful in other contexts such as, for example, mirrored storage commands.

FIG. 1depicts a system30. System30includes a computing device32serving as a data storage system (DSS), a network34, and one or more hosts36that may serve as initiators of commands to the DSS computing device32over the network34. In some embodiments, system30may also include one or more other devices connected to computing device32over network34. Computing device32may be any kind of computing device, such as, for example, a personal computer, workstation, server computer, enterprise server, DSS cabinet, laptop computer, tablet computes, smart phone, mobile computer, etc. Typically, computing device32is a DSS.

Host36may be any kind of computing device capable of sending data storage commands to computing device32over network34, such as, for example, a personal computer, workstation, server computer, enterprise server, laptop computer, tablet computes, smart phone, mobile computer, etc. Typically, host36is a workstation, server computer, or enterprise server. In some embodiments, host36may run a hypervisor (not depicted), allowing various virtual machines (not depicted) to execute in a virtualized environment (not depicted) thereon.

Computing device32includes network interface circuitry33, processing circuitry38, storage interface circuitry42, persistent data storage44, and memory40. Computing device32may also include other components as are well-known in the art.

Network interface circuitry33may include one or more Ethernet cards, cellular modems, FC adapters, Wireless Fidelity (Wi-Fi) wireless networking adapters, and/or other devices for connecting to network34. Processing circuitry38may be any kind of processor or set of processors configured to perform operations, such as, for example, a microprocessor, a multi-core microprocessor, a digital signal processor, a system on a chip, a collection of electronic circuits, a similar kind of controller, or any combination of the above.

Persistent storage44may include any kind of persistent storage devices, such as, for example, hard disk drives, solid-state storage devices, flash drives, etc. Storage interface circuitry42controls and provides access to persistent storage44. Storage interface circuitry42may include, for example, SCSI, SAS, ATA, SATA, Fibre Channel (FC), and/or other similar controllers and ports. Persistent storage44may be arranged in various configurations, such as, for example in RAID groups that provide storage striped or mirrored across several disks (with optional parity data, e.g., in RAID-5) as RAID disks. In some embodiments, each RAID disk may be subdivided into Flare LUNs, which may themselves be subdivided into slices (not depicted) of, for example, 256 MB or 1 gigabyte size. These slices may be assigned as backing store to a common block file system (CBFS) such as that provided by EMC Corp. of Hopkinton, Mass.). CBFS58manages one or more files backed by these slices in a mapped manner, and CBFS58is then able to present one or more of these files to host36as one or more respective logical disks.

Memory40may be any kind of digital system memory, such as, for example, random access memory (RAM). Memory40stores one or more operating systems (OSes) in operation (e.g., Linux, UNIX, Windows, MacOS, or a similar operating system; not depicted), various applications (not depicted) executing on processing circuitry38, and various drivers48,51,54(and their respective subcomponents) some of which may be arranged in a driver stack46. Memory40also includes a CBFS58in operation.

In some embodiments, memory40may also include a persistent storage portion (not depicted). Persistent storage portion of memory40may be made up of one or more persistent storage devices, such as, for example, disks. Persistent storage portion of memory40or persistent storage44is configured to store programs and data even while the computing device32is powered off. The OS and the applications are typically stored in persistent storage44so that they may be loaded into a system portion of memory40from persistent storage44upon a system restart. These applications and drivers48,51,54, when stored in non-transient form either in the volatile portion of memory40or in persistent storage44or in persistent portion of memory40, form a computer program product. The processing circuitry38running one or more of these applications or drivers48,51,54thus forms a specialized circuit constructed and arranged to carry out the various processes described herein.

Memory40stores at least three drivers48,51,54that operate as part of storage driver stack46. At the top of driver stack46is a data mover library driver48which interfaces with host36and provides access to logical disks presented by the CBFS58so that the host36can issue storage commands to the data mover library driver48and receive respective responses from the data mover library driver48. In the middle of driver stack46is a mapping driver51(also referred to as the MLU), and at the bottom of the driver stack46is a physical storage driver54that is able to communicate with the storage interface circuitry42, providing the MLU51with access to the individual slices, FLUs, and RAID disks of persistent storage44. In some embodiments there may be additional drivers (not depicted) within driver stack46above and/or below the MLU51.

MLU51is a multi-part driver having an upper arm50and a lower arm52. In addition, MLU51is arranged in a “C-Clamp” configuration, allowing it to communicate with various other software modules without using inter-driver communication. A fixture stack60includes a stack of fixture modules61(depicted as fixtures61(a),61(b), . . .61(m)). I/O coordinator (IOC)56sits at the bottom of the fixture stack60. Upper arm50is able to send I/O descriptors, which it obtains from I/O descriptor (IOD) allocator module62, down the fixture stack60towards the lower arm52. This allows the various fixtures61and IOC56to make various changes and translations to storage operations prior to final processing by the lower arm52of the MLU51. Fixtures61typically perform services ancillary to storage. An example fixture61is a compression module, while another example fixture is a de-duplication module.

In operation, host36sends a combined storage command70(e.g., an XCopy Lite or VAAI XCOPY command, generically referred to as an Xcopy command) to data mover library driver48. For example, in the case of an Xcopy command, the combined storage command70requests that data be copied from a source to a destination. The source and destination may each be specified by referring to a specific logical disk presented by the CBFS58and an offset (e.g., in blocks) and length (e.g., in blocks also). For example, the Xcopy command may indicate that Logical disk7at offset10should be copied to logical disk5at offset243, the copied region having a length of 15 blocks.

Command70is referred to as being a “combined” command because data mover library driver48breaks the command into two parts71,73. In the case of an Xcopy, inter-driver source command70lists a command type of copy source and specifies a source location in the host's address space (i.e., a logical location on a logical disk) from where the data is to be copied. Typically this source location includes a logical disk number, an offset, and a length.

Also in the case of an Xcopy, inter-driver destination command73lists a command type of copy destination and specifies a destination location in the host's address space (i.e., a logical location on a logical disk) to where the data is to be copied. Typically this destination location includes a logical disk number and an offset. The length is not needed since it is already specified in the inter-driver source command70, but, in some embodiments, it may be included anyway.

Inter-driver commands71,73may take the form of I/O Request Packets (IRPs) holding an IOCTL or DeviceIoControl system call as is well-known in the art.

In one embodiment, data mover library driver48sends inter-driver source command71down the storage driver stack46to the MLU51. Upon receipt, upper arm50of the MLU51sends back an inter-driver rendezvous command72requesting a paired command. In response to rendezvous command72, data mover library driver48sends inter-driver destination command73down the storage driver stack46to the MLU51. In response, upper arm50and data mover library driver48perform a rendezvous pairing negotiation75, resulting in a pairing structure76being generated within upper arm50to indicate that inter-driver commands71,73are paired as siblings.

In order to fulfill the pair of commands71,73, upper arm50creates (e.g., by calling IOD allocator62) a destination IOD data structure77and a source IOD data structure78and sends those down the fixture stack60to the IOC56. In one embodiment upper arm50sends destination IOD77prior to sending the source IOD78. The source IOD78and destination IOD77also contain the source location and destination location respectively in the logical address space. In one embodiment, an IOD77,78has a stacked data structure with a public field at the top and a set of private fields that hold data specific to specific fixtures61in the fixture stack60. In addition, there may be shared fields between the private fields that allow adjacent fixtures61to pass information from one to the next. The logical source location may be stored within the public field of source IOD78, and the logical destination location may be stored within the public field of destination IOD77. Further detail with respect to what is stored within the public field of source IOD78may be found below in connection withFIG. 2. Further detail with respect to what is stored within the public field of destination IOD77may be found below in connection withFIG. 3.

IOC56serves to translate between the physical addressing scheme used by physical storage driver54(e.g., referring to RAID disks and offsets within those disk) and the logical addressing scheme presented by CBFS58. Thus, when it receives the destination IOD77and source IOD78, it sends a Map_for_Read command80to CBFS58in order to obtain a Map_for_Read response81mapping of the logical source location to physical storage, which may take the form of a set of source extent descriptors82(depicted as source extent descriptors82(a),82(b), . . . ,82(n)). This may be illustrated with reference toFIG. 2.

FIG. 2illustrates an example arrangement100of source mapping. Source IOD78includes a logical source disk identifier102(such as a logical unit number [LUN]), a logical source offset104, and a source length106. As depicted in the example, the logical source identifier102identifies logical source disk110, logical source offset104indicates that the source starts at an offset of 50 blocks (e.g., 8-kilobyte-sized blocks) into the logical source disk110, and source length106indicates that the source to be copied is 100 blocks long. This corresponds to a logical source region112from block50through (but not including) block150of logical source disk110. The Map_for_Read command80returns a set of source extent descriptors82(depicted as three source extent descriptors82(a),82(b),82(c)). Each source extent descriptor82includes a respective physical disk identifier120, physical source extent offset122, and physical source extent length124. It can be seen that logical source region112may be broken up into three divisions, regions114(a),114(b), and114(c) which are each backed by different physically-contiguous source extents134(a),134(b),134(c), respectively. As depicted, physical source extent134(a) is on physical source disk130(1) (as identified by physical source disk identifier120(a)), beginning at block50(as identified by physical source extent offset122(a)) and extending for 25 blocks (as identified by physical source extent length124(a)). Physical source extent134(b) is on physical source disk130(2) (as identified by physical source disk identifier120(b)), beginning at block25(as identified by physical source extent offset122(b)) and extending for 50 blocks (as identified by physical source extent length124(b)). Physical source extent134(c) is on physical source disk130(1) (as identified by physical source disk identifier120(c)), beginning at block100(as identified by physical source extent offset122(c)) and extending for 25 blocks (as identified by physical source extent length124(c)).

It should be noted that it is possible for a logical source region114(q) to not actually be backed by any underlying physical source extent134(q) (the unallocated backing store case). In such a case, in some embodiments, the corresponding source extent descriptor82(q) may include a null value for120(q),122(q). Consequently, since there is no underlying source extents, there is nothing to write to the destination, therefore, the write operation described below in connection withFIG. 3does not occur. Rather, a map for deallocation for the unallocated extents is requested. In other words, if the IOC56detects there is an unallocated extent on the source that is to be copied to the destination, a “hole punch” is issued using a Map-for-Deallocate command on the destination. Since the IOC56is at the bottom of the stack, the fixtures would not see the hole punch request if IOC56bypasses the stack. In order to prevent bypassing the fixtures, the IOC56can call the MLU lower arm52with the a special disparate write sub-I/O tracking structures (SIOTS) for the transfer and the MLU lower arm52will internally call the MLU upper arm50to issue a “hole punch” request. Since this call will be received by the IOC56, it will create a new I/O tracking structures (IOTS) for the request and initiate a Map-for-Deallocate command on the destination. The MLU lower arm52may iterate over the entire range of requested extents. Once the entire hole punch request is completed the disparate SIOTS is completed back to IOC56. The MLU lower arm52calls the MLU upper arm50where the MLU upper arm50will create a new IOD and pass it down to the fixture stack. IOC56will then receive this as an IOTS (IOTS is a part of the IOD) and initiate a Map-for-Deallocate request on the destination. Map-for-Deallocate semantics allows the request to underrun (i.e., less blocks zeroed than requested) and the result is returned back to MLU upper arm50which returns back to MLU lower arm52. If MLU lower arm52notices that the number of blocks zeroed is less than the number requested, it will issue a new request to cover the remaining range. This process will continue until the entire original request is deallocated. Copying unallocated extents is discussed in further detail in conjunction withFIG. 6.

Once the allocated physical source extents134have been identified with reference to the source extent descriptors82, IOC56may perform a set of operations on each identified allocated physical source extent134. Thus, for a particular allocated physical source extent134(x), IOC56identifies the physical destination locations to be written to for that physical source extent134(x). IOC56begins by sending a Map_for_Write command83to CBFS58for that particular allocated physical source extent134(x) in order to obtain a disparate write buffer84in response, effectively mapping the logical destination locations corresponding to logical source region114(x) to physical storage, making modifications to the disparate write buffer84to yield a modified disparate write buffer85, and then issuing a copy command86and receiving a copy response91. This may be illustrated with reference toFIG. 3.

FIG. 3illustrates an example arrangement200of destination mapping. Destination IOD77includes a logical destination disk identifier202(such as a LUN), a logical destination offset204, and, optionally, a destination length (which is the same as source length106). As depicted in the example, the logical destination identifier202identifies logical destination disk210, logical destination offset204indicates that the destination starts at an offset of 10 blocks into the logical destination disk210, and length106indicates that the destination to be copied to is 100 blocks long. This corresponds to a logical destination region212from block10through (but not including) block110of logical destination disk210. As depicted, logical destination region212may be broken up into two divisions, regions214(a) (having length10) and214(b) (having length90) which are each backed by different respective physically-contiguous destination extents (not depicted).

FIG. 3also illustrates what the Map_for_Write command83returns for a first allocated physical source extent134(a), as an example. Since allocated physical source extent134(a) has a length124(a) of 25 blocks, the corresponding portions of logical destination region212will include all of region214(a) and only the first 15 blocks of region214(b). Thus the returned disparate write buffer84for first allocated physical source extent134(a) includes two destination extent descriptors282(1),282(2). Each destination extent descriptor282includes a respective physical destination disk identifier220, physical destination extent offset222, and physical destination extent length224, which combine to define a respective physically-contiguous destination extent234. As depicted, physical destination extent234(1) is on physical destination disk230(A) (as identified by physical destination disk identifier220(1)), beginning at block20(as identified by physical destination extent offset222(1)) and extending for 10 blocks (as identified by physical destination extent length224(1)). Physical destination extent234(2) is on physical destination disk230(B) (as identified by physical destination disk identifier220(2)), beginning at block5(as identified by physical destination extent offset222(2)) and extending for 15 blocks (as identified by physical destination extent length224(2)).

Received disparate write buffer84includes a set of nodes240(depicted as nodes240(1),240(2),240(3), . . . ). Each node240may include an operation code242. Some of the nodes (e.g., nodes240(1) and240(2)) correspond to the physical destination extents234; thus node240(1) includes destination extent descriptor282(1) and node240(2) includes destination extent descriptor282(2). For these nodes, the operation code242is a write code, because the Map_for_Write command is normally used to return instructions for writing to physical extents. Returned disparate write buffer84may also include one or more additional nodes240(e.g., node240(3)) having a metadata operation code242(3) and storing metadata244to also be written to physical storage. This metadata244may be, for example, metadata used in a journaling filesystem (e.g., persistent file data cache (PFDC)).

Because IOC56is not interested in performing a simple write operation but rather wants the physical storage driver54to perform a copy operation, IOC56modifies the received disparate write buffer84to create a modified disparate write buffer85(although, in some embodiments, IOC56may make the modifications directly to the received disparate write buffer84without making a copy) that will be useful for copying. In particular, IOC56modifies the operation codes242(1),242(2) from write commands to copy commands in modified operation codes242′(1),242′(2). In addition, IOC56also inserts a source descriptor for each copy operation into the modified nodes240′. Thus, modified node240′(1) now becomes a copy operation from a physical location defined by physical source descriptor82(a)-1to a physical location (i.e., region234(1)) defined by physical destination descriptor282(1), and modified node240′(2) now becomes a copy operation from a physical location defined by physical source descriptor82(a)-2to a physical location (i.e., region234(2)) defined by physical destination descriptor282(2). The physical location defined by physical source descriptor82(a)-1and the physical location defined by physical source descriptor82(a)-2are both subsets of the physical location defined by physical source descriptor82(a). Metadata node240(3) is not modified in modified disparate write buffer85.

IOC56sends a copy IOD86down to lower arm52. In some embodiments, the copy IOD86includes the modified disparate write buffer85, while in other embodiments, IOD86at least includes information allowing the various copy operations described by nodes240′(1),240′(2) to be reconstructed. Lower arm52is then able to use this information to send at least one inter-driver copy command87down the driver stack46to the physical driver54. Inter-driver copy command87may take the form of an IRP holding an IOCTL or DeviceIoControl system call. In some embodiments, one inter-driver copy command87may include several (or all) copy commands from the various nodes240′ having copy operation codes242′. In other embodiments, lower arm52breaks up the copy commands from the various nodes240′ having copy operation codes242′ into a separate inter-driver copy command87for each. In any case, physical storage driver54performs the one or more inter-driver copy commands87by sending one or more low-level copy commands88(or constituent sub-commands) to persistent storage44, receiving low-level copy responses89in response. Then, physical storage driver54is able to issue a response91for each copy IOD86back to the IOC56. IOC56may then repeat for each remaining identified allocated physical source extent134.

Once IOC56completes the copy for all of the identified allocated physical source extents134, it may send a completion IOD93,94back up the fixture stack60to the upper arm50to indicate completion (whether success or failure) of each of destination IOD77and source IOD78. Because upper arm50knows that these IODs are paired together by pairing structure76, it is then able to send a unified inter-driver response95back to the data mover library driver48indicating either success on both destination IOD77and source IOD78or failure (if either destination IOD77and source IOD78failed). Data mover library driver48is then able to send an Xcopy response96indicating either the success or failure of the Xcopy back to the initiator host36.

Although described in the context of an Xcopy operation, the pairing aspect may be used in other contexts as well, such as, for example, for mirrored write operations.

FIG. 4illustrates an example method300performed by computing device32. It should be understood that any time a piece of software (e.g., drivers48,51,54or their components; fixtures61; IOC56; CBFS58; etc.) is described as performing a method, process, step, or function, in actuality what is meant is that the computing device32on which that piece of software is running performs the method, process, step, or function when executing that piece of software on its processing circuitry38.

It should be understood that, withinFIG. 4, sub-step355is drawn with a dashed border because it is only used in some embodiments of method300. In addition, one or more of the other steps or sub-steps of method300may also be omitted in some embodiments. Similarly, in some embodiments, one or more steps or sub-steps may be combined together or performed in a different order. Method300is performed by computing device32, more specifically by mapping driver/MLU51running on processing circuitry38in conjunction with various other system components.

Preliminarily, before step310, initiator host36sends a combined storage command (e.g., an Xcopy command; a write command directed at a mirrored location; etc.) to a top-level driver (e.g., data mover library driver48) of a storage driver stack46running on computing device32. That top-level driver48then splits the combined storage command into at least two related sub-commands71,73, each of which may be considered a data storage command (DSC) in its own right. A DSC may take the form of an IRP having an IOCTL. For example, an Xcopy command may be split into an inter-driver source copy command an inter-driver destination copy command, while a write command directed at a mirrored area may be split into two inter-driver write commands, each directed at a different one of the mirrored destinations.

In step310, MLU51(e.g., at its upper arm50) receives a first DSC (e.g., inter-driver command71) from storage driver stack46. Since this DSC was received first, it may be designated as the primary command.

In step320, MLU51(e.g., at its upper arm50) receives a second DSC (e.g., inter-driver command73) from storage driver stack46. Since this DSC was received second, it may be designated as the secondary command. The primary and secondary commands are peer commands, but the primary command may be the one that is reported back on if there is no error. In some embodiments, step320is performed in response to the MLU51requesting a second DSC from the data mover library driver48having a same identifier as the DSC received in step310(indicating that the two DSCs are related).

In step330, MLU51(e.g., at its upper arm50) may determine that the first and second DSCs71,73are both related aspects of a single combined storage command70. This may be done intrinsically by receiving the second DSC73in response to requesting a related DSC or MLU51may recognize that the DSCs71,73are related in some other manner (e.g., by comparing a token or identifier delivered therewith).

In step340, in response to determining (in step330) that the two DSCs71,73are related, MLU51(e.g., at its upper arm50) establishes a pairing structure76to pair the two related DSCs71,73together.

In step350, MLU51(e.g., upper arm50in communication with fixture stack60and lower arm52) fulfills the combined storage command70by fulfilling both DSCs71,73with reference to the pairing structure76. In one embodiment (e.g., when the combined storage command70is an Xcopy command), the lower arm52(e.g., based on an instruction86from the IOC56) sends a “copy” DSC87to physical storage driver54directing the physical storage driver54to copy data from a physical source address to a physical destination address, the physical storage driver54being able to fulfill the copy DSC87without communicating with any driver in the storage driver stack46above the mapping driver50. This is in contrast to other approaches in which mapping driver51sends separate read and write DSCs to the physical storage driver54, which then must communicate back with the data mover library driver48to determine that the data that is read from the source is to be written to the same buffer that will be written to the destination. In some embodiments, step350is performed in conjunction with method400as described below in connection withFIG. 5.

If the combined storage command70is successfully fulfilled by the MLU51, then operation proceeds with step360. In step360, MLU51(e.g., at its upper arm50) reports completion of the primary DSC71identified by the paired structure76by sending inter-driver response95back to the data mover library driver48in response to the first DSC71. No response is sent back to the data mover library driver48in response to the second DSC73.

If the combined storage command70is not successfully fulfilled by the MLU51(e.g., if there is an error or if the initiator host36sends a cancellation command that is able to terminate the paired DSCs71,73before completing), then operation proceeds with step370. In step370, MLU51(e.g., at its upper arm50) reports an error on both DSCs71,73identified by the paired structure76by sending a first inter-driver error response95back to the data mover library driver48in response to the first DSC71and a second inter-driver error response95back to the data mover library driver48in response to the second DSC73.

FIG. 5illustrates an example method400performed by computing device32. It should be understood that, withinFIG. 5, various steps or sub-steps of method400may be omitted in some embodiments. Similarly, in some embodiments, one or more steps or sub-steps may be combined together or performed in a different order. Method400is performed by computing device32, more specifically by IOC56running on processing circuitry38in conjunction with various other system components.

Preliminarily, before steps410and420, upper arm50sends destination IOD77and source IOD78down the fixture stack60towards the IOC56as part of an Xcopy command, as described above.

In step410, IOC56receives a logical source descriptor structure (e.g., Source IOD78) that specifies a logical source disk110(e.g., using logical source disk identifier102), a logical source offset104, and a length106for a copy operation. In parallel, in step420, IOC56receives a logical destination descriptor structure (e.g., Destination IOD77) that specifies a logical destination disk210(e.g., using logical destination disk identifier202), and a logical source offset204for the copy operation.

Then, in step430, IOC56requests (e.g., by calling Map_for_Read) a physical mapping of the source IOD78from a CBFS58configured to present a file as a logical disk.

In step440, IOC56receives, in response to the Map_for_Read request80of step430, a first set of storage extent descriptors (e.g., source extent descriptors82) each storage extent descriptor82of the first set describing a respective physical storage extent134, the first set representing a mapping of the source descriptor structure onto physical storage. The first set of storage extent descriptors includes only source extent descriptors82that point to actual physical storage extents134. However, if there are any received source extent descriptors82that have null pointers (i.e., the underlying storage is not allocated), then those unallocated extents are excluded from the first set and are instead part of the third set of method500, below. If there is a third set of received source extent descriptors82that have null pointers, then those are processed separately in method500at this point.

In step450, IOC56begins going through the physical source extent descriptors of the first set one at a time. For a current physical source extent descriptor82(x), IOC56requests a physical mapping (e.g., by calling Map_for_Write) of a corresponding location of the logical destination descriptor structure (e.g., destination IOD77) from the CBFS58. Thus for example, referring toFIG. 2, when the current physical source extent descriptor82(x) is physical source extent descriptor82(b), since it corresponds to logical source offsets25through75, Map_for_Write is called on logical offsets25through75of logical destination region212as identified by destination IOD77.

Then, in step460, in response to the Map_for_Write request83, IOC56receives a second set of storage extent descriptors (e.g., physical destination extent descriptors282), each storage extent descriptor of the second set describing a respective physical storage extent234, the second set representing a mapping of the corresponding location of the destination descriptor structure (e.g., destination IOD77) onto physical storage. In some embodiments, step460includes sub-step465in which IOC56obtains disparate write buffer84, which has a set of nodes240, each having a write command (denoted by a write operation code242) directed at a different low-level extent234(described by a physical destination extent descriptors282) on the destination. Disparate write buffer84also includes one or more additional nodes240with (e.g., PFDC) metadata244.

Then, in step470, IOC56sends a copy request to a physical storage driver54directing the physical storage driver54to copy data from the physical storage extent134of that storage extent descriptor82of the first set to the physical storage extents234of the second set. In sub-step472, IOC modifies the nodes240of disparate write buffer84to become copy commands rather than write commands and inserting respective physical source descriptors82(s)(t) for appropriate s, t as described above in connection withFIG. 3(thereby creating modified disparate write buffer85having modified nodes240′). In sub-step474, IOC56sends the modified disparate write buffer85(or, in other embodiments, copy commands derived from the modified nodes240′ of modified disparate write buffer85, or just their arguments) as an IOD86to the lower arm52for the MLU51to pass on to the physical storage driver54for low-level processing.

Once the copy request is successfully completed, operation proceeds with step480, in which the current physical source extent descriptor82(x) is incremented to82(x+1), and then operation loops back to step450until all physical source extent descriptors82of the first set have been looped through, at which point method400concludes.

FIG. 6illustrates an example method500performed by computing device32. It should be understood that, withinFIG. 6, various steps or sub-steps of method500may be omitted in some embodiments. Similarly, in some embodiments, one or more steps or sub-steps may be combined together or performed in a different order. Method500is performed by computing device32, more specifically by IOC56running on processing circuitry38in conjunction with various other system components.

Method500is an embodiment directed to copying unallocated source extents to a destination. The method500may, but need not, be performed in parallel with steps440-480of method400. In step510, IOC56receives, in response to the Map_for_Read request80of step430, a third set of storage extent descriptors (e.g., source extent descriptors82) each storage extent descriptor82of the third set describing a subset114of region112defined by the logical source descriptor structure (e.g., source IOD78), each subset114of the region112including a logical offset and length124on the logical source disk110representing a region114that currently lacks any physical storage backing (e.g., the physical source extent offset122for the physical source extent descriptor82corresponding to that region114is null or otherwise invalid indicating that the physical source extent descriptors82is for an unallocated region).

In step520, IOC56begins going through the unallocated region physical source extent descriptors82of the third set one at a time. For a current unallocated region physical source extent descriptor82(x), IOC56sends to the MLU51an indication that a portion of the region212of logical destination descriptor structure (e.g., destination IOD77) corresponding to the region114of that unallocated region physical source storage extent descriptor82should be unallocated, the MLU51being configured to send a logical deallocation descriptor structure (deallocation IOD, not depicted) back to the IOC56. In some embodiments, this is accomplished via sub-step525. In sub-step525, the IOC56sends the indication to the lower arm52of MLU51, which communicated with the upper arm50of MLU51, which is then able to pass the deallocation IOD (which it created by calling IOD allocator62) down the fixture stack60to the IOC56. By having the deallocation IOD pass through the fixture stack60, the fixtures61may be made aware of the “hole” within the destination.

In step530, IOC56receives the deallocation IOD from the MLU51(e.g., from the upper arm50of the MLU51via the fixture stack60). In response, in step540, IOC56sends a request to the CBFS58(e.g., a Map_for_Deallocate call) to deallocate physical storage backing corresponding to a region define by the deallocation IOD. In response, in step540, IOC56receives a confirmation of the deallocation.

Operation then proceeds with step560, in which the current unallocated region physical source extent descriptor82within the third set is incremented to the next element of the third set, and then operation loops back to step520until all unallocated region source extent descriptors82of the third set have been looped through, at which point method500concludes.

Thus, techniques have been presented for allowing a mapping driver51in a driver stack46to be made aware of a relationship between related source and destination inter-driver calls71,73so that it can pair them together and make integrated copy calls86,87down to a physical storage driver54at the bottom of the stack46. This pairing76may also be useful in other contexts such as, for example, mirrored storage commands.

For example, although various embodiments have been described as being methods, software embodying these methods is also included. Thus, one embodiment includes a tangible non-transitory computer-readable storage medium (such as, for example, a hard disk, a floppy disk, an optical disk, flash memory, etc.) programmed with instructions, which, when performed by a computer or a set of computers, cause one or more of the methods described in various embodiments to be performed. Another embodiment includes a computer that is programmed to perform one or more of the methods described in various embodiments.

It should be understood that all embodiments that have been described may be combined in all possible combinations with each other, except to the extent that such combinations have been explicitly excluded.

Finally, even if a technique, method, apparatus, or other concept is specifically labeled as “background” or “conventional,” Applicant makes no admission that such technique, method, apparatus, or other concept is actually prior art under 35 U.S.C. § 102 or 35 U.S.C. § 103, such determination being a legal determination that depends upon many factors, not all of which are known to Applicant at this time.