Capturing snapshots in storage system

Abstract

The invention relates to capturing snapshots in a storage system. Example implementations relate to operations in a storage system. Example implementations include receiving a write to a first data unit of a first address in a volume, and populating a first volume entry in a base volume table with a reference to a first version table. The example implementation also includes generating a first snapshot table and a second version table in response to detecting the snapshot trigger event, where the first snapshot table is a copy of the base volume table. The example implementation further includes, after generating the first snapshot table, receiving a write to a second data unit of a second address in the volume, and populating a second volume entry in the base volume table with a reference to the second version table.

Description

Background Technology

[0001] Computing devices may include components such as processors, memory, cache systems, and storage devices. Storage devices may include hard disk drives that use magnetic media to store and retrieve blocks of data. Some storage systems can transfer data between different locations or devices. For example, some systems may transfer and store copies of important data for archiving and recovery purposes. Attached Figure Description

[0002] Some implementation methods are described with reference to the following figures.

[0003] Figure 1 This is a schematic diagram of an example storage system according to some implementation methods.

[0004] Figures 2A to 2C These are illustrations of example operations based on some implementation methods.

[0005] Figure 3 This is a diagram illustrating an example process based on some implementation methods.

[0006] Figures 4A to 4H These are illustrations of example operations based on some implementation methods.

[0007] Figure 5 This is a diagram illustrating an example process based on some implementation methods.

[0008] Figure 6 This is a diagram illustrating an example process based on some implementation methods.

[0009] Figure 7 This is a schematic diagram of an example computing device according to some implementation methods.

[0010] Figure 8 This is a diagram illustrating an example process based on some implementation methods.

[0011] Figure 9 This is a diagram of an example machine-readable medium storing instructions according to some implementation methods.

[0012] Throughout the accompanying drawings, the same reference numerals denote similar but not necessarily identical elements. The drawings are not necessarily drawn to scale, and some parts may be enlarged to illustrate the examples more clearly. Furthermore, the drawings provide examples and / or embodiments consistent with the description; however, the description is not limited to the examples and / or embodiments provided in the drawings. Detailed Implementation

[0013] In this disclosure, unless the context clearly indicates otherwise, the terms “a,” “an,” or “the” are intended to include the plural form as well. Similarly, when used in this disclosure, the terms “includes / including / comprises / comprising” or “have / having” indicate the presence of the stated element but do not preclude the presence or addition of other elements.

[0014] In some examples, a computing system may persistently store data on one or more storage devices. For example, a server may store a data set on a local storage array and may also store a backup copy of the data set on a remote backup device. In some examples, the backup copy may be stored in a form different from the data set. For example, the backup copy may include a deduplicated representation of the data set. As used herein, "storage system" may include a storage device or an array of storage devices. A storage system may also include storage controllers(s) that manage access to the storage device(s). A "data unit" may refer to any portion of data in a storage system that can be individually identified. In some cases, a data unit may refer to a block, a collection of blocks, or any other portion of data.

[0015] In some examples, the storage system may store data units in persistent storage devices. Persistent storage devices may be implemented using one or more or combinations of persistent (e.g., non-volatile) storage devices (such as multiple disk-based storage devices, such as multiple hard disk drives (HDDs)), multiple solid-state drives (SSDs), such as multiple flash storage devices), etc. As used herein, "controller" may refer to hardware processing circuitry, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or other hardware processing circuitry. Alternatively, "controller" may refer to a combination of hardware processing circuitry and machine-readable instructions (software and / or firmware) executable on the hardware processing circuitry.

[0016] In some examples, a storage system may implement logical volumes or virtual volumes as an abstraction of persistent storage devices. For instance, a storage system may store data units in logical addresses mapped to (e.g., in one or more persistent storage devices) physical storage locations. This logical address may be referred to as an "offset" within the volume. In some examples, the storage system may include a metadata structure for storing information about the stored data units. For example, a mapping table may record the logical address and corresponding physical storage location of each data unit stored in the storage system.

[0017] In some examples, storage systems can use metadata structures to capture snapshots of storage volumes. As used herein, a "snapshot" is a representation of the data contained in (or other) storage volumes (or other collections of data) at a specific point in time (also referred to herein as a "snapshot time"). For example, a mapping table can be copied at each snapshot time, and the copied mapping table can be stored for later retrieval. In this example, each stored mapping table can represent a snapshot capturing the state (e.g., logical address and physical location) of the stored data units at the corresponding snapshot time. In this way, snapshots can be used to reconstruct the stored data units at the respective snapshot times (e.g., for recovery from failure events, historical analysis, etc.).

[0018] In some examples, the physical storage location of a data unit may change after multiple snapshots are captured (e.g., due to storage disk defragmentation, storage disk failure, etc.). However, in such examples, it may be necessary to update each snapshot to reflect the changed physical storage location. For example, this update could involve transferring a relatively large number of mapping tables from persistent storage to memory, determining which mapping tables are affected by the changed physical location, updating each affected mapping table, and transferring the updated mapping tables back from memory to persistent storage. Therefore, such updates can involve significant processing and network bandwidth requirements.

[0019] According to some embodiments of this disclosure, a storage system may use a metadata structure including volume tables and version tables. Entries in both the volume tables and version tables can be indexed to different addresses (e.g., offsets) within the volume. A volume table may include a base volume table and any number of snapshot tables. Furthermore, each version table is associated with a different snapshot within the volume (also referred to herein as a snapshot "version" or "version number"). When a data block is written to an address, the corresponding entry in the base volume table (i.e., the entry indexed to that address) can be populated with a reference to the current version table (e.g., version one table). The corresponding entry in the version table may store a pointer to the physical location of the data block and may also store a reference count (e.g., to indicate how many volume tables reference that entry in the version table). To generate a snapshot, the base volume table can be copied to create a snapshot table, and a new version table can be initialized. Snapshots can be recorded using a combination of snapshot tables and version tables associated with the same snapshot version. Subsequently, if the physical location of a data block changes, only the version table, which includes a pointer to that physical location, must be updated. Therefore, some embodiments can reduce the amount of processing and data transfer required to maintain accurate snapshots. References are provided below. Figures 1 to 8 The disclosed techniques for capturing snapshots will be discussed further.

[0020] Figures 1 to 2C - example storage system

[0021] Figure 1 An example of a storage system 100 according to some embodiments is shown, including a storage controller 110, a memory 115, and a persistent storage device 140. The persistent storage device 140 may include one or more non-transitory storage media, such as a hard disk drive (HDD), a solid-state drive (SSD), an optical disk, or a combination thereof. The memory 115 may be implemented using a semiconductor memory such as random access memory (RAM). In some examples, the storage controller 110 may be implemented via hardware (e.g., electronic circuitry) or a combination of hardware and programming (e.g., including at least one processor and instructions executable by said at least one processor and stored on at least one machine-readable storage medium).

[0022] In some implementations, persistent storage device 140 may include a volume 150 (or multiple volumes 150). Volume 150 may be an abstraction (e.g., a logical or virtual volume) of the physical storage location of the stored data units 155. For example, volume 150 may be arranged in addresses (e.g., offsets within volume 150) mapped to different physical locations of the stored data units 155 (e.g., locations in different drives in an array). For example, now referring to... Figure 2A The diagram illustrates command 230, which writes data unit "X" to address "4" in volume 210. As shown, address "4" is mapped to the physical location 222 of data unit "X" in physical storage device 220. Further, as... Figure 2B As shown, command 232 writes the data unit "Y" to address "1", which is mapped to location 224 in physical storage device 220. Furthermore, as... Figure 2C As shown, command 234 can write the data unit "Z" to address "3", which is mapped to location 226 in physical storage device 220.

[0023] Refer again Figure 1 In some embodiments, memory 115 may include memory engine 120. As used herein, "engine" may refer to machine-readable instructions executable on hardware processing circuitry (e.g., software instructions and / or firmware instructions stored on at least one machine-readable storage medium). For example, memory engine 120 may be implemented as program code executed by memory controller 110 and loaded into memory 115. Further, in some embodiments, the program code of memory engine 120 may be stored in persistent storage device 140. Alternatively, "engine" may refer to hardware processing circuitry (e.g., any or some combination of a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or another hardware processing circuitry), or a combination of hardware processing circuitry and machine-readable instructions.

[0024] In some implementations, storage engine 120 can manage operations of adding, removing, or removing data units 155 in volume 150. For example, storage engine 120 can receive or read input data 105 (e.g., via write commands) and can store copies (or multiple copies) of the received data as stored data units 155. Further, storage engine 120 can receive requests for stored data units 155 (e.g., via query or read commands) and, in response, can retrieve and return the requested data unit 155.

[0025] In some implementations, persistent storage 140 may include metadata 160. As shown, metadata 160 may include a volume table 161, a version table 164, and a version counter 166. Volume table 161 and version table 164 may include entries indexed to different addresses (e.g., offsets) within volume 150. Volume table 161 may include a base table 162 and any number of snapshot tables 163. Further, each version table 164 may be associated with a different snapshot version of volume 150.

[0026] In some implementations, version counter 166 may indicate the version number of the next subsequent snapshot (i.e., the upcoming snapshot to be captured). For example, before capturing the first snapshot of volume 150 (i.e., the initial snapshot) (i.e., before any snapshots have been captured), version counter 166 may indicate the number "1". Further, after capturing the first snapshot, version counter 166 may immediately increment to indicate the number "2". In some implementations, metadata 160 may be used to map logical addresses and physical storage locations and to record snapshots of volume 150. For example, snapshots (e.g., version-one snapshots) may be recorded using a combination of snapshot table 163 and version table 164 of the same version (e.g., snapshot-one table 163 and version-one table 164). Reference below Figures 3 to 8 Further discussion of example implementations of metadata 160.

[0027] Please note that, although Figure 1 Metadata elements 161, 162, 163, and 164 are illustrated as “tables,” but the implementation is not limited in this respect. For example, it is conceivable that other types or forms of data structures (e.g., relational databases, object databases, Extensible Markup Language (XML) databases, or files, flat files, etc.) can be used to implement metadata elements 161, 162, 163, and 164.

[0028] Figures 3 to 4H - example process for capturing a snapshot

[0029] Figure 3An example process 300 for capturing a snapshot, according to some embodiments, is shown. For illustrative purposes, reference may be made below to examples illustrating some embodiments. Figures 4A to 4H The details of process 300 are described. However, other implementations are also possible. In some examples, a storage controller 110 (such as...) can be used. Figure 1 Process 300 is executed as shown. Process 300 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by (multiple) processors). Machine-readable instructions can be stored in a non-transitory computer-readable medium such as an optical storage device, a semiconductor storage device, or a magnetic storage device. Machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0030] refer to Figure 3 Box 310 may include writing a data unit received at an address in the logical volume. Box 315 may include identifying an entry in the underlying volume table associated with the written address. Box 320 may include determining the current snapshot version number. Box 325 may include populating an entry in the underlying volume table with the snapshot version number.

[0031] Now for reference Figure 4A This illustrates an example of receiving the first write command 410 before capturing the initial snapshot of the volume. Figure 4A In the example shown, the controller (e.g., Figure 1 The storage controller 110 shown receives a first write command 410 to write data unit "A" to the volume (e.g., Figure 1 Address "1" in volume 150 (shown in the diagram). In response to write command 410, the controller reads the current version data structure 420 to determine the current snapshot version "V1". Snapshot version "V1" may correspond to the initial (i.e., sequential, first) snapshot number and may indicate that the initial snapshot is still pending (i.e., has not yet been captured). Further, the controller accesses base table 430 and identifies the entry indexed to write address "1" (specified in write command 410). Further, the controller populates the identified entry in base table 430 with an indication or identifier of the current snapshot version (e.g., "V1" or "1").

[0032] The current version data structure 420 can roughly correspond to version counter 166 (e.g.) Figure 1 Example implementation shown). Further, base table 430 may substantially correspond to base table 162 (e.g., ...). Figure 1 Example implementation shown). In some implementations, base table 430 may include multiple entries, where each entry represents (or is indexed to) a volume (e.g., Figure 1Different addresses in volume 150 shown. Further, in some embodiments, each entry of base table 430 may initially be empty (i.e., not filled with any data) and may be filled when a data unit is written to the address represented by that entry. In addition, in some embodiments, each filled entry of base table 430 stores only an indication of the snapshot version (e.g., the current version (e.g., "V1" or "1")).

[0033] Refer again Figure 3 Box 330 may include storing the data unit in a physical location mapped to a write address. Box 335 may include populating the entries in the current version table with pointers to the physical locations. Box 340 may include populating the entries in the current version table with a reference count equal to one.

[0034] For example, refer to again Figure 4A The controller stores data unit "A" at location "05" in physical storage device 450. Further, the controller accesses the V1 version table 440 (i.e., the version table associated with the current snapshot version "V1") and identifies entry "1" in the V1 version table 440 (i.e., the entry indexed to write address "1"). The controller populates entry "1" in the V1 version table 440 with a pointer to physical location "05". Figure 4A As shown, the controller also fills the entry "1" in Table 440 of version V1 with a reference count equal to "1".

[0035] Version table 440 of V1 can roughly correspond to version table 164 (e.g., Figure 1 The example implementation is shown below. In some implementations, the V1 version table 440 may include multiple entries, each representing a different address in the volume. Further, in some implementations, each entry of the V1 version table 440 may initially be empty and may be filled in as data units are written to the address represented by that entry.

[0036] Refer again Figure 3 Decision box 345 may include determining whether a trigger event for a snapshot has been detected. Upon receiving a negative determination (“No”), process 300 may return to box 310 (e.g., to continue receiving writes of data cells).

[0037] Now for reference Figure 4B This shows the process before capturing the first snapshot, but after receiving the first write command 410 (as shown). Figure 4A (As shown) This is an example of receiving a second write command 412 afterward. Figure 4BIn the example shown, the controller receives a second write command 412 to write data unit "B" to address "4" in the volume. In response to the second write command 412, the controller identifies entry "4" in base table 430 (i.e., the entry indexed to write address "4") and populates entry "4" in base table 430 with the indication "V1" of the current snapshot version. The controller stores data unit "B" at location "03" in physical storage device 450. Further, the controller populates entry "4" in version V1 table 440 with a pointer to physical location "03". Figure 4B As shown, the controller also populates entry "4" of V1 version table 440 with a reference count equal to "1".

[0038] Refer again Figure 3 If it is determined at decision box 345 that a trigger event for a snapshot has been detected (“Yes”), process 300 can continue at box 350, including creating a snapshot table as a copy of the base volume table. Box 355 may include incrementing the reference count by one for each entry in the current version table. Box 360 may include incrementing the version number by one. Box 365 may include creating a new version table associated with the incremented version number. After box 365, process 300 can return to box 310 (e.g., to continue receiving writes of data units).

[0039] Now for reference Figure 4C This shows that upon receiving the second write command 412 (e.g., Figure 4B (As shown) An example was detected after the first snapshot triggered 414. Figure 4C In the example shown, the controller detects a first snapshot trigger 414 and, in response, sets (e.g., increments) the current snapshot version to (e.g., in the current version data structure 420) "V2". The controller creates a V2 version table 442 (i.e., a version table associated with the current snapshot version "V2"). Further, the controller generates a V1 snapshot table 432 by copying the current base table 430 (i.e., the base table 430 that exists during the copying process).

[0040] like Figure 4C As shown, entries “1” and “4” in V1 snapshot table 432 are filled with the same indications (e.g., “V1”) of the snapshot version, which are also filled into entries “1” and “4” in base table 430 (i.e., filled in response to write commands 410 and 412). Therefore, since entry “1” in V1 snapshot table 432 is now referenced by entries in both base table 430 and V1 snapshot table 432, the reference count for entry “1” in V1 version table 440 is set (i.e., incremented) to “2”. Similarly, the reference count for entry “4” in V1 version table 440 is also set to “2”.

[0041] In some implementations, the V1 snapshot table 432 may be a static data structure that repeats the state of the base table 430 at a specific point in time (i.e., when the first snapshot trigger 414 is detected). The V1 snapshot table 432 may substantially correspond to the snapshot table 163 (e.g., ...). Figure 1 Example implementation shown). Further, version table 442 may substantially correspond to version table 164 (e.g., Figure 1 Example implementation (as shown). For example... Figure 4C As shown, version V2 table 442 may include multiple entries, each representing a different address within the volume. In some implementations, each entry in version V2 table 442 may initially be empty and may be filled as data units are written to the address represented by that entry.

[0042] In some implementations, the snapshot trigger 414 can be an event that causes a new snapshot to be captured (also referred to herein as a "trigger event"). For example, a trigger event can be a user command to initiate a snapshot capture, a scheduled snapshot capture, the expiration of a periodic timer, and so on. Other examples or combinations of trigger events are possible.

[0043] Now for reference Figure 4D This shows the capture of the first snapshot (e.g., as shown in the image). Figure 4C (As shown) This is an example of receiving a third write command 416 afterward. Figure 4D In the example shown, the controller receives a third write command 416 to write data unit "C" to address "2" in the volume. In response to the third write command 416, the controller reads the current version data structure 420 to determine the current snapshot version "V2". The controller then populates entry "2" in the base table 430 with the indication "V2" of the current snapshot version.

[0044] like Figure 4D As shown, the controller stores the data unit "C" at location "01" in physical storage device 450. Further, the controller populates entry "2" of version V2 table 442 with a pointer to physical location "01". The controller also populates entry "2" of version V2 table 442 with a reference count equal to "1". In some embodiments, snapshot table 432 is not updated to reflect any write commands received after the current snapshot version has incremented to "V2".

[0045] Now for reference Figure 4E This shows that upon receiving the third write command 416 (e.g., Figure 4D (As shown) An example of a second snapshot triggering 417 was detected afterward. Figure 4EIn the example shown, the controller detects a second snapshot trigger 417 and, in response, sets (e.g., increments) the current snapshot version to (e.g., in the current version data structure 420) "V3". The controller creates a V3 version table 444 and generates a V2 snapshot table 434 by copying the current base table 430.

[0046] like Figure 4E As shown, entries “1” and “4” in V2 snapshot table 434 are filled with the same indications (i.e., “V1”) as those in the snapshot version, which are also filled with entries “1” and “4” in base table 430. Further, the reference counts in entries “1” and “4” of V1 version table 440 are set (i.e., incremented) to “3”, indicating that these entries “1” and “4” are referenced by three different volume tables (i.e., base table 430, V1 snapshot table 432, and V2 snapshot table 434). Additionally, entry “2” in V2 snapshot table 434 is filled with the same indications (i.e., “V2”) as those in the snapshot version, which are also filled with entries “2” in base table 430. Therefore, the reference count in entry “2” of V2 version table 442 is set to “2”, indicating that entry “2” is referenced by two different volume tables (i.e., base table 430 and V2 snapshot table 434).

[0047] Now for reference Figure 4F This shows the capture of a second snapshot (e.g., as shown in the image). Figure 4E (As shown) is an example of receiving the fourth write command 418 afterward. Figure 4F In the example shown, the controller receives a fourth write command 418 to write data unit "X" to address "5" in the volume. In response to the fourth write command 418, the controller reads the current version data structure 420 to determine the current snapshot version "V3". The controller then fills entry "5" of the base table 430 with the indication "V3" of the current snapshot version. The controller stores data unit "X" at location "07" in the physical storage device 450. Further, the controller fills entry "5" of the V3 version table 444 with a pointer to the physical location "07". Figure 4F As shown, the controller also populates entry "5" in V3 version table 444 with a reference count equal to "1".

[0048] Now for reference Figure 4G This illustrates an example of receiving a fifth write command 419 after receiving a fourth write command 418. Figure 4G In the example shown, the controller receives a fifth write command 419 to write data unit "Y" to address "1" in the volume. Note that, as... Figure 4AAs shown, the first write command 412 has previously written data unit "A" to address "1" in the volume. Therefore, the fifth write command 419 causes data unit "Y" to replace or overwrite data unit "A" at address "1" in the volume.

[0049] In response to the fifth write command 419, the controller reads the current version data structure 420 to determine the current snapshot version "V3". The controller then overwrites the previous value of entry "1" in the base table 430 with the indication "V3" of the current snapshot version. The controller stores the data unit "Y" at location "02" in the physical storage device 450 and fills entry "1" in the V3 version table 444 with a pointer to the physical location "02".

[0050] like Figure 4G As shown, entry "1" in base table 430 references entry "1" in version V3 table 444. Therefore, the controller populates entry "1" in version V3 table 444 with a reference count equal to "1", thereby indicating that entry "1" in version V3 table 444 is referenced by a single volume table (i.e., base table 430). Further, the controller modifies entry "1" in version V1 table 444 to reduce the reference count from "3" to "2", thereby indicating that entry "1" in version V1 table 444 is now referenced by two different volume tables (i.e., V1 snapshot table 432 and V2 snapshot table 434).

[0051] Please note that data unit "A", previously written to address "1" (and now overwritten by data unit "Y"), is still stored at location "05" in physical storage device 450. Therefore, the first snapshot (i.e., snapshot version "V1" recorded via the combination of V1 snapshot table 432 and V1 version table 440) continues to correctly reference the stored data unit "A" and can therefore be used to restore or rebuild the first snapshot. Similarly, the second snapshot (i.e., snapshot version "V2" recorded via the combination of V2 snapshot table 434 and V2 version table 442) also continues to correctly reference the stored data unit "A" and can therefore be used to restore or rebuild the second snapshot.

[0052] Now for reference Figure 4H This illustrates an example of a stored data unit "B" (in physical storage device 450) moving 460 from position "03" to "06". For example, the movement 460 could be caused by a defragmentation process of physical storage device 450, a failure of a storage device included in physical storage device 450, etc. Figure 4HAs shown, in response to movement 460, the controller accesses entry "04" in version table 440 and replaces the pointer to position "03" with a pointer to position "06". Therefore, movement 460 only needs to update a single version table (i.e., version table 440) without making any changes to the volume tables (i.e., base table 430, version table 432, and version table 434) or the remaining version tables (i.e., version table 442 and version table 444). In this way, some implementations can reduce the amount of processing and data transfer required to maintain accurate snapshots.

[0053] Figure 5 - example process for reading snapshot data

[0054] Figure 5 An example process 500 for reading snapshot data according to some embodiments is shown. For illustrative purposes, reference may be made below to examples illustrating some embodiments. Figures 1 to 4H The details of process 500 are described. However, other implementations are also possible. In some examples, a storage controller 110 (such as...) can be used. Figure 1 Process 500 is executed as shown. Process 500 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by (multiple) processors). Machine-readable instructions can be stored in a non-transitory computer-readable medium such as an optical storage device, a semiconductor storage device, or a magnetic storage device. Machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0055] Box 510 may include receiving a read request for a data address in a snapshot version. Box 520 may include identifying a snapshot table associated with a specific snapshot version. Box 530 may include identifying a snapshot table entry associated with a data address in the snapshot table. Box 540 may include determining the snapshot version indicated by the snapshot table entry.

[0056] Box 550 may include identifying a version table associated with the determined snapshot version. Box 560 may include identifying version table entries associated with data addresses within the version table. Box 570 may include reading pointers to physical storage locations from the version table entries. Box 580 may include using pointers to read data units stored in the physical storage location.

[0057] For example, refer to Figure 4H The controller receives the first query or request (not in Figure 4H(As shown in the diagram) to read address "1" recorded in snapshot version "V2". In response to the first query, the controller accesses entry "1" of V2 snapshot table 434 (i.e., the snapshot table corresponding to the requested snapshot version "V2") and reads the version identifier "V1" stored in entry "1" of V2 snapshot table 434. Further, the controller accesses entry "1" of V1 version table 440 (i.e., the version table corresponding to version identifier "V1") and reads pointer "05" stored in entry "1" of V1 version table 440. The controller then uses pointer "05" to read (at location "05" in physical storage device 450) data unit "A" and returns data unit "A" as the result of the first query.

[0058] In another example, still referencing Figure 4H The controller receives a second query or request (not in Figure 4H (As shown in the diagram) to read address "2" recorded in snapshot version "V2". In response to the second query, the controller accesses entry "2" of V2 snapshot table 434 and reads the version identifier "V2" stored in entry "2" of V2 snapshot table 434. Further, the controller accesses entry "2" of V2 version table 442 (i.e., the version table corresponding to version identifier "V2") and reads pointer "01" stored in entry "2" of V2 version table 442. The controller then uses pointer "01" to read data unit "C" (stored at location "1" of physical storage device 450) and returns data unit "C" as the result of the second query.

[0059] Figure 6 - example housekeeping process

[0060] Figure 6 An example process 600 for housekeeping according to some embodiments is shown. For illustrative purposes, reference may be made below to examples illustrating some embodiments. Figures 1 to 4H The details of process 600 are described. However, other implementations are also possible. In some examples, a storage controller 110 (such as...) can be used. Figure 1 Process 600 is executed as shown. Process 600 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by (multiple) processors). Machine-readable instructions can be stored in a non-transitory computer-readable medium such as an optical storage device, a semiconductor storage device, or a magnetic storage device. Machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0061] Box 610 may include receiving a command for deleting a specific snapshot version. Box 620 may include deleting the snapshot table associated with a specific snapshot version. For example, refer to... Figure 4H The controller receives commands or requests (not in...) Figure 4H (As shown in the diagram) to delete snapshot version "V2". In response to this command, the controller deletes snapshot table 434 (i.e., the snapshot table corresponding to the requested snapshot version "V2").

[0062] Refer again Figure 6 Box 630 may include accessing a version table associated with a specific snapshot version. Box 640 may include identifying entries that have been populated in the version table. Box 650 may include decrementing the reference count by one in the identified entries. For example, references Figure 4H The controller accesses version table 442 (i.e., the version table corresponding to snapshot version "V2"). Further, the controller determines that entry "2" is the only entry populated in version table 442, and in response, decrements the reference counter included in entry "2" in version table 442.

[0063] Refer again Figure 6 Decision box 660 may include determining whether the reference count (decreased by one in box 650) is equal to zero. Upon receiving an affirmative determination (“yes”), process 600 may continue in box 670, including reading a pointer to the physical storage location from the identified entry. Box 680 may include deleting the data unit stored in the physical storage location using the pointer. Box 690 may include clearing the identified entry in the version table. For example, reference... Figure 4H The controller determines whether the reference counter (included in entry "2" of V2 version table 442) has a zero value. If so, the controller reads pointer "01" stored in entry "2" of V2 version table 442 and uses pointer "01" to delete data cell "C" (stored at location "01" in physical storage device 450). Further, the controller clears or otherwise depopulates entry "2" of V2 version table 442.

[0064] Refer again Figure 6 Following box 690, if it is determined at decision box 660 that the reference count is not equal to zero, process 600 can continue at decision box 695, including determining whether the version table has any remaining fill entries. Upon receiving an affirmative determination (“Yes”), process 600 can return to box 640 (i.e., to identify and process another fill entry in the version table). Otherwise, if it is determined at decision box 695 that the version table does not have any remaining fill entries (“No”), process 600 can complete.

[0065] In some implementations, housekeeping process 600 may use a reference counter (e.g., included in entry "2" of table 442 in version 2) to determine whether a stored data unit is no longer referenced by any snapshot, and if so, free up storage space for other uses. In this way, some implementations can provide efficient housekeeping of storage space without having to load and analyze multiple metadata structures to identify obsolete data units. Therefore, some implementations can reduce the processing and network resource consumption of performing housekeeping on stored data.

[0066] Figure 7 -Example computing device

[0067] Figure 7 A schematic diagram of an example computing device 700 is shown. In some examples, computing device 700 may substantially correspond to storage system 100 (e.g., Figure 1 (As shown). As shown, computing device 700 may include some or all of the following: hardware processor 702, memory 704, and machine-readable storage device 705 including instructions 710-750. Machine-readable storage device 705 may be a non-transitory medium. Instructions 710-750 may be executed by hardware processor 702 or by a processing engine included in hardware processor 702.

[0068] Instruction 710 can be executed to receive a write to a first data unit at a first address in the volume. Instruction 720 can be executed to, in response to receiving the write to the first data unit, populate the first volume entry in the base volume table with a reference to the first version table. For example, refer to... Figure 4A The controller receives a first write command 410 to write data unit "A" to address "1" in the volume. In response to the write command 410, the controller reads the current version data structure 420 to determine the current snapshot version "V1". Further, the controller accesses the base table 430 and identifies the entry indexed to the write address "1" (specified in the write command 410). Further, the controller populates the identified entry in the base table 430 with an indication or identifier of the current snapshot version (e.g., "V1"). In some implementations, the identifier of the current snapshot version (in the identified entry in the base table 430) may reference or otherwise identify the V1 version table 440 (i.e., the version table associated with the current snapshot version "V1").

[0069] Instruction 730 can be executed in response to the detection of a snapshot trigger event to generate a first snapshot table and a second version table, wherein the first snapshot table is a copy of the base volume table. For example, refer to... Figure 4CThe controller detects the first snapshot trigger 414 and, in response, sets (e.g., increments) the current snapshot version to (e.g., in the current version data structure 420) "V2". The controller creates a V2 version table 442 (i.e., a version table associated with the current snapshot version "V2"). Further, the controller generates a V1 snapshot table 432 by copying the current base table 430 (i.e., the base table 430 that exists during the copying process).

[0070] Instruction 740 can be executed to receive a write to a second data unit at a second address in the volume after the first snapshot table has been generated. Instruction 750 can be executed to populate the second volume entry in the base volume table with a reference to the second version table in response to the received write to the second data unit. For example, refer to... Figure 4D The controller receives a third write command 416 to write the data unit "C" to address "2" in the volume. In response to the third write command 416, the controller reads the current version data structure 420 to determine the current snapshot version "V2". The controller then fills entry "2" of the base table 430 with the indication "V2" of the current snapshot version. Further, the controller stores the data unit "C" at location "01" in the physical storage device 450 and fills entry "2" of the V2 version table 442 with a pointer to the physical location "01". The controller also fills entry "2" of the V2 version table 442 with a reference count equal to "1".

[0071] Figure 8 - Example process for capturing snapshots

[0072] Figure 8 An example process 800 for capturing a snapshot, according to some implementations, is shown. In some examples, a storage controller 110 (such as...) can be used. Figure 1 Process 800 is executed as shown. Process 800 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by (multiple) processors). Machine-readable instructions can be stored in a non-transitory computer-readable medium such as optical storage devices, semiconductor storage devices, or magnetic storage devices. Machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0073] Box 810 may include a write to a first data unit at a first address in the volume received by the controller. Box 820 may include, in response to receiving the write to the first data unit, the controller populating a first volume entry in the base volume table with a reference to a first version table. Box 830 may include, in response to detecting a snapshot trigger event, the controller generating a first snapshot table and a second version table, wherein the first snapshot table is a copy of the base volume table.

[0074] Box 840 may include, after the first snapshot table is generated, the controller receiving a write to a second data unit at a second address in the volume. Box 820 may include, in response to receiving the write to the second data unit, the controller populating a second volume entry in the base volume table with a reference to a second version table. Boxes 810-850 may generally correspond to the above-mentioned reference instructions 710-750 (e.g., Figure 7 The example described is shown below.

[0075] Figure 9 -Example machine-readable media

[0076] Figure 9 A machine-readable medium 900 storing instructions 910-950 according to some embodiments is shown. Instructions 910-950 can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc. The machine-readable medium 900 can be a non-transitory storage medium, such as an optical storage medium, a semiconductor storage medium, or a magnetic storage medium. Instructions 910-950 may generally correspond to the referenced instructions 710-750 above (e.g., ...). Figure 7 The example described is shown below.

[0077] Instruction 910 can be executed to receive a write to a first data unit at a first address in the volume. Instruction 920 can be executed to populate a first volume entry in the base volume table with a reference to a first version table in response to receiving the write to the first data unit. Instruction 930 can be executed to generate a first snapshot table and a second version table in response to detecting a snapshot trigger event, wherein the first snapshot table is a copy of the base volume table.

[0078] Instruction 940 can be executed to receive a write to a second data unit at a second address in the volume after the first snapshot table has been generated. Instruction 950 can be executed to populate the second volume entry in the base volume table with a reference to the second version table in response to the received write to the second data unit.

[0079] in conclusion

[0080] According to the implementation described herein, the storage system can use a metadata structure including a base volume table, a snapshot table, and a version table. When a data block is written to an address, the corresponding entry in the base volume table can be populated with a reference to the current version table. The corresponding entry in the version table can store a pointer to the physical location of the data block and can also store a reference count. To generate a snapshot, the base volume can be replicated to create a snapshot table, and a new version table can be initialized. Snapshots can be recorded using a combination of snapshot tables and version tables associated with the same snapshot version. Subsequently, if the physical location of a data block changes, only the version table, which includes a pointer to that physical location, must be updated. Therefore, some implementations (e.g., compared to alternative methods involving updating physical location data in multiple metadata structures) can reduce the amount of processing and data transfer required to account for changes in the physical location of stored data.

[0081] Furthermore, as referenced above Figure 6 As discussed, some implementations may use a reference counter (e.g., included in entry "2" of Table 442 in version V2) to determine whether a stored data unit is no longer referenced by any snapshot, and if so, free up storage space for other uses. In this way, some implementations can provide efficient housekeeping of storage space without having to load and analyze multiple metadata structures to identify obsolete data units. Therefore, some implementations can reduce the amount of processing and network resources consumed in performing housekeeping on stored data.

[0082] Furthermore, in some implementations, the metadata structure can be identified and accessed by snapshot versions. Therefore, if metadata needs to be updated or accessed within a specified time frame, the corresponding metadata can be updated or accessed in a relatively simple manner, thereby improving the efficiency of metadata changes or reads. Additionally, the metadata of stored data can be identified by the time period in which the data was updated, rather than by the location where the data is stored. Moreover, if it is necessary to determine differences between two volumes, these differences can be determined by simply comparing the metadata of the two volumes (e.g., without having to access their corresponding physical location information and load that information into memory).

[0083] Note that, although Figures 1 to 9 Various examples are shown, but the implementation methods are not limited in this respect. For example, see references... Figure 1 It is conceivable that storage system 100 may include additional devices and / or components, fewer components, different components, different arrangements, etc. In another example, it is conceivable that the functionality of the aforementioned storage controller 110 may be included in any other engine or software of storage system 100. Other combinations and / or variations are also possible.

[0084] Data and instructions are stored in a corresponding storage device implemented as one or more computer-readable or machine-readable storage media. Storage media include various forms of non-transitory memory, including: semiconductor memory devices such as dynamic random access memory or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed floppy disks and removable disks; other magnetic media, including magnetic tape; optical media such as optical discs (CDs) or digital video discs (DVDs); or other types of storage devices.

[0085] Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system with potentially multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or artifact). An article or artifact can refer to any single or multiple manufactured components. The one or more storage media may be located in a machine executing the machine-readable instructions or at a remote site from which the machine-readable instructions can be downloaded for execution via a network.

[0086] In the foregoing description, numerous details have been set forth to facilitate understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A computing device, comprising: processor; Memory; as well as A machine-readable storage device storing instructions that can be executed by the processor to perform the following operations: Received a write to the first data unit at the first address in the volume; In response to receiving a write to the first data unit, the first volume entry in the base volume table is populated with a reference to the first version table; In response to the detection of a snapshot trigger event, a first snapshot table and a second version table are generated, wherein the first snapshot table is a copy of the base volume table; After generating the first snapshot table, a write to the second data unit at the second address in the volume is received; and In response to receiving a write to the second data unit, the second volume entry in the base volume table is populated with a reference to the second version table.

2. The computing device of claim 1, further comprising instructions executable by the processor to perform the following operations: The first version entry in the first version table is filled with a first pointer pointing to the physical storage location of the first data unit; and The second version entry in the second version table is filled with a second pointer pointing to the physical storage location of the second data unit.

3. The computing device as claimed in claim 2, wherein: The first volume entry is indexed to the first address; The entries in the second volume are indexed to the second address; The first version entry is indexed to the first address; and The second version entry is indexed to the second address.

4. The computing device of claim 2, further comprising instructions executable by the processor to perform the following operations: The first count of volume entries referencing the first version entry is stored in the first version entry of the first version table; and The second count of the volume entries that reference the second version entry is stored in the second version entry of the second version table.

5. The computing device as claimed in claim 1, wherein, The reference to the first version table is the first snapshot version number, and the reference to the second version table is the second snapshot version number.

6. The computing device of claim 5, further comprising instructions executable by the processor to perform the following operations: In response to detecting the snapshot trigger event, the snapshot version counter is incremented from the first snapshot version number to the second snapshot version number.

7. The computing device of claim 1, further comprising instructions executable by the processor to perform the following operations: Receives a read request for a data address in a specified snapshot version; Identify the specific snapshot table associated with the specified snapshot version; Identify snapshot table entries associated with the data address in the specific snapshot table; Determine the specific snapshot version indicated by the snapshot table entry; Identify the specific version table associated with the particular snapshot version; Identify the specific version entry associated with the data address in the specific version table; Read a specific pointer to a specific physical storage location from the specific version table entry; as well as Use the specific pointer to read the specific data unit stored in the specific physical storage location.

8. The computing device as claimed in claim 1, wherein, The second version table includes multiple volume entries, and each of the multiple volume entries is associated with a different address of the volume.

9. The computing device of claim 1, wherein: The first snapshot table is included in multiple snapshot tables; The first version table and the second version table are included in multiple version tables; and Multiple snapshot versions are recorded as a combination of the multiple snapshot tables and the multiple version tables.

10. A method comprising: The controller receives a write to the first data unit at the first address in the volume; In response to receiving a write to the first data unit, the controller populates the first volume entry in the base volume table with a reference to the first version table; In response to the detection of a snapshot trigger event, the controller generates a first snapshot table and a second version table, wherein the first snapshot table is a copy of the base volume table; After generating the first snapshot table, the controller receives a write to a second data unit at a second address in the volume; and In response to receiving a write to the second data unit, the controller populates the second volume entry in the base volume table with a reference to the second version table.

11. The method of claim 10, further comprising: The first version entry in the first version table is filled with a first pointer pointing to the physical storage location of the first data unit; as well as The second version entry in the second version table is filled with a second pointer pointing to the physical storage location of the second data unit.

12. The method of claim 11, further comprising: The first count of the volume entries that reference the first version entry is stored in the first version entry of the first version table; as well as The second count of the volume entries that reference the second version entry is stored in the second version entry of the second version table.

13. The method of claim 10, wherein, The reference to the first version table is the first snapshot version number, and the reference to the second version table is the second snapshot version number.

14. The method of claim 13, further comprising: In response to detecting the snapshot trigger event, the snapshot version counter is incremented from the first snapshot version number to the second snapshot version number.

15. The method of claim 13, further comprising: Receives a read request for a data address in a specified snapshot version; Identify the specific snapshot table associated with the specified snapshot version; Identify snapshot table entries associated with the data address in the specific snapshot table; Determine the specific snapshot version indicated by the snapshot table entry; Identify the specific version table associated with the particular snapshot version; Identify the specific version entry associated with the data address in the specific version table; Read a specific pointer to a specific physical storage location from the specific version table entry; as well as Use the specific pointer to read the specific data unit stored in the specific physical storage location.

16. A non-transitory machine-readable medium storing instructions that, when executed, cause a processor to perform the following operations: Received a write to the first data unit at the first address in the volume; In response to receiving a write to the first data unit, the first volume entry in the base volume table is populated with a reference to the first version table; In response to the detection of a snapshot trigger event, a first snapshot table and a second version table are generated, wherein the first snapshot table is a copy of the base volume table; After generating the first snapshot table, a write to the second data unit at the second address in the volume is received; and In response to receiving a write to the second data unit, the second volume entry in the base volume table is populated with a reference to the second version table.

17. The non-transitory machine-readable medium of claim 16, comprising instructions executable by the processor to perform the following operations: The first version entry in the first version table is filled with a first pointer pointing to the physical storage location of the first data unit; and The second version entry in the second version table is filled with a second pointer pointing to the physical storage location of the second data unit.

18. The non-transitory machine-readable medium of claim 17, comprising instructions executable by the processor to perform the following operations: The first count of volume entries referencing the first version entry is stored in the first version entry of the first version table; and The second count of the volume entries that reference the second version entry is stored in the second version entry of the second version table.

19. The non-transitory machine-readable medium of claim 16, comprising instructions executable by the processor to perform the following operations: In response to detecting the snapshot trigger event, the snapshot version counter is incremented from the first snapshot version number to the second snapshot version number. in, The reference to the first version table is the first snapshot version number, and the reference to the second version table is the second snapshot version number.

20. The non-transitory machine-readable medium of claim 16, comprising instructions executable by the processor to perform the following operations: Receives a read request for a data address in a specified snapshot version; Identify the specific snapshot table associated with the specified snapshot version; Identify snapshot table entries associated with the data address in the specific snapshot table; Determine the specific snapshot version indicated by the snapshot table entry; Identify the specific version table associated with the particular snapshot version; Identify the specific version entry associated with the data address in the specific version table; Read a specific pointer to a specific physical storage location from the specific version table entry; as well as Use the specific pointer to read the specific data unit stored in the specific physical storage location.

Images