CAPTURING SNAPSHOTS IN A STORAGE SYSTEM

Abstract

Example implementations refer to operations in a storage system. An example implementation includes receiving a write operation of a first data unit to a first address on a disk and populating a first disk entry in a basic disk table with a reference to a first version table. The example implementation also includes creating a first snapshot table and a second version table in response to the detection of a snapshot trigger event, where the first snapshot table is a copy of the basic disk table. After creating the first snapshot table, the example implementation also includes receiving a write operation of a second data unit to a second address on the disk and populating a second disk entry in the basic disk table with a reference to a second version table.

Description

background

[0001] Computer devices can include components such as a processor, memory, a cache system, and a storage device. The storage device can include a hard disk drive, which uses a magnetic medium to store and retrieve blocks of data. Some storage systems can transfer data between different locations or devices. For example, some systems can transfer and store copies of important data for archiving and recovery purposes. Brief description of the drawings

[0002] Some embodiments are described with reference to the following illustrations. Fig. is a schematic diagram of an exemplary storage system in accordance with some implementations. Fig. These are illustrations of example processes in accordance with some implementations. Fig. This is an illustration of a sample process in accordance with some implementations. Fig. These are illustrations of example processes in accordance with some implementations. Fig. This is an illustration of a sample process in accordance with some implementations. Fig. This is an illustration of a sample process in accordance with some implementations. Fig. is a schematic diagram of an exemplary computer device in accordance with some implementations. Fig. This is an illustration of a sample process in accordance with some implementations. Fig. is a diagram of an example of a machine-readable medium that stores instructions in accordance with some implementations.

[0003] In the drawings, identical reference numbers denote similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated for better illustration of the example shown. Furthermore, the drawings contain examples and / or embodiments that correspond to the description; however, the description is not limited to the examples and / or embodiments shown in the drawings. Detailed description

[0004] In this disclosure, the use of the terms "a," "an," or "the" also includes the plural forms, unless the context clearly indicates otherwise. Similarly, the terms "contains," "including," "comprises," "encompasses," "have," or "have," when used in this disclosure, specify the presence of the elements indicated, but do not exclude the presence or addition of other elements.

[0005] In some examples, a computer system can permanently store data on one or more storage devices. For instance, a server might store a collection of data on a local storage array and also store a backup of that data collection on a remote backup device. In some examples, the backup might be stored in a different format than the data collection. For example, the backup might be a deduplicated representation of the data collection. The term "storage system" as used here can include a single storage device or an array of storage devices. A storage system can also include one or more storage controllers that manage access to the storage device(s). A "data unit" can refer to any portion of the data that can be separately identified within the storage system.In some cases, a data unit may refer to a chunk, a collection of chunks, or another part of data.

[0006] In some examples, a storage system can store data units in persistent memory. Persistent storage can be implemented using one or more persistent (e.g., non-volatile) storage devices, such as disk-based storage devices (e.g., hard disk drives (HDDs)), solid-state devices (SSDs), such as flash memory devices, or similar, or a combination thereof. As used herein, a "controller" can refer to a hardware processing circuit that 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, a "control unit" can refer to a combination of a hardware processing circuit and machine-readable instructions (software and / or firmware) that can be executed on the hardware processing circuit.

[0007] In some examples, a storage system can implement a logical or virtual volume as an abstraction of persistent storage. For instance, the storage system can store data units at logical addresses that correspond to physical storage locations (e.g., in one or more persistent storage devices). Such logical addresses can be referred to as "offsets" on a storage volume. In some examples, the storage system can include metadata structures to store information about the stored data units. For example, an allocation table can record the logical address and corresponding physical location of each data unit stored in the storage system.

[0008] In some examples, the storage system can use a metadata structure to capture a snapshot of a storage volume. As used here, a "snapshot" is a representation of the data contained in one or more storage volumes (or other data collections) at a specific point in time (also referred to here as the "snapshot time"). For example, a mapping table can be copied at various snapshot times, and the copied mapping tables can be stored for later retrieval. In such examples, each stored mapping table can represent a snapshot that captures the state of the stored data units (e.g., logical addresses and physical locations) at a corresponding snapshot time. In this way, the snapshots can be used to reconstruct the stored data units as they were at the various snapshot times (e.g.,for recovery after a fault event, for historical analysis, etc.).

[0009] In some examples, after a series of snapshots has been taken, the physical locations of the data units may change (e.g., due to disk defragmentation, disk failure, etc.). In such examples, each snapshot must be updated to reflect the changed physical locations. Such an update might involve, for example, transferring a relatively large number of mapping tables from persistent storage to memory, determining which mapping tables are affected by the changed physical locations, updating each affected mapping table, and transferring the updated mapping tables from memory back to persistent storage. Therefore, such an update can require a significant amount of processing and network bandwidth.

[0010] In accordance with some implementations of this disclosure, a storage system can use metadata structures that include disk tables and version tables. The entries in both the disk tables and the version tables can be indexed to different addresses (e.g., offsets) on a disk. The disk tables can include a base disk table and any number of snapshot tables. Furthermore, each version table is associated with a different snapshot of the disk (also referred to here as the snapshot "version" or "version number"). When a block of data is written to an address, the corresponding entry in the base disk table (i.e., the entry indexed to that address) can be populated with a reference to a current version table (e.g., the version 1 table).The corresponding entry in the version table can store a pointer to the physical location of the data block and also a reference counter (e.g., to indicate how many disk tables reference this version table entry). To create a snapshot, the base disk table can be copied to create a snapshot table, and a new version table can be initialized. The snapshot can be recorded by combining the snapshot table and the version table associated with the same snapshot version. Subsequently, if the physical location of the data block is changed, only the version table containing the pointer to the physical location needs to be updated. Accordingly, some implementations can reduce the processing and data transfer overhead required to obtain accurate snapshots.The disclosed technique for capturing snapshots is described further below with reference to the . Fig. . Fig. 1-2C - Example of a storage system

[0011] Fig. Figure 1 shows an example of a storage system 100, which includes a storage controller 110, a memory 115, and persistent memory 140 according to some implementations. The persistent memory 140 can include one or more non-transient storage media such as hard disk drives (HDDs), solid-state drives (SSDs), optical disks, etc., or a combination thereof. The memory 115 can be implemented in semiconductor memory such as random-access memory (RAM). In some examples, the storage controller 110 can be implemented by hardware (e.g., electronic circuits) or by a combination of hardware and programming (e.g., with at least one processor and instructions that can be executed by the at least one processor and are stored on at least one machine-readable storage medium).

[0012] In some implementations, the persistent memory 140 can contain a disk 150 (or multiple disks 150). The disk 150 can be an abstraction (e.g., a logical or virtual disk) of the physical storage locations of the stored data units 155. For example, the disk 150 can be arranged in addresses (e.g., offsets in the disk 150) that correspond to different physical storage locations (e.g., locations in different drives in an array) that store the data units 155. Fig. For example, instruction 230 is shown for writing a data unit "X" to an address "4" in a data carrier 210. As shown, the address "4" is mapped to the physical memory location 222 of the data unit "X" in physical memory 220. As shown in Fig. As shown, instruction 232 writes a data unit “Y” to an address “1”, which is mapped to a memory location 224 in physical memory 220. As shown in Fig. As shown, an instruction 234 can write a data unit “Z” to an address “3” which is mapped to a memory location 226 in physical memory 220.

[0013] Referring again to Fig. In some implementations, memory 115 may contain a memory engine 120. As used here, an "engine" can refer to machine-readable instructions (e.g., software instructions and / or firmware instructions stored on at least one machine-readable storage medium) that can be executed on a hardware processing circuit. For example, the memory engine 120 may be implemented as program code that is executed by the memory controller 110 and loaded into memory 115. Furthermore, in some implementations, the program code for the memory module 120 may be stored in permanent memory 140. Alternatively, an "engine" may refer to a hardware processing circuit (e.g.,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 circuit) or a combination of a hardware processing circuit and machine-readable instructions.

[0014] In some implementations, the memory module 120 can manage operations to add, remove, or delete data units 155 on the storage medium 150. For example, the memory module 120 can receive or read input data 105 (e.g., via a write command) and store a copy (or multiple copies) of the received data as stored data units 155. Furthermore, the memory module 120 can receive requests for the stored data units 155 (e.g., via a query or read command) and retrieve and return the requested data units 155 in response.

[0015] In some implementations, the persistent storage 140 can contain metadata 160. As shown, the metadata 160 can contain volume tables 161, version tables 164, and a version counter 166. The volume tables 161 and the version tables 164 can contain entries indexed to different addresses (e.g., offsets) on the volume 150. The volume tables 161 can contain a base table 162 and any number of snapshot tables 163. Furthermore, each version table 164 can be associated with a different snapshot version of the volume 150.

[0016] In some implementations, version counter 166 can display the version number of the next snapshot (i.e., the upcoming snapshot awaiting capture). For example, before the capture of the first (i.e., initial) snapshot of disk 150 (i.e., before any snapshots have been captured), version counter 166 can display the number "1". Immediately after the capture of the first snapshot, version counter 166 can be incremented to display the number "2". In some implementations, metadata 160 can be used to map logical addresses and physical memory locations and to record snapshots of disk 150. For example, a snapshot (e.g., a snapshot of version 1) can be recorded by combining the snapshot table 163 and the version table 164 of the same version (e.g., the Snapshot 1 table 163 and the Version 1 table 164).Exemplary implementations of the metadata 160 are described below with reference to the . Fig. .

[0017] Note that the in Fig. Although the metadata elements 161, 162, 163, and 164 are represented as "tables," implementations are not limited in this respect. For example, it is conceivable that metadata elements 161, 162, 163, and 164 could be implemented using other types or forms of data structures (e.g., relational database, object database, XML database or file, flat file, etc.). Fig. 3-4H - Example procedure for capturing snapshots

[0018] Fig. This shows an example process 300 for capturing snapshots in accordance with several implementations. For illustration, details of process 300 are given below with reference to the Fig. As described, the examples show some implementations. However, other implementations are also possible. In some examples, process 300 can be run using memory controller 110 (shown in Fig. Process 300 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions that can be executed by one or more processors). The machine-readable instructions can be stored on a non-transient, computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing machine, multiple processing machines, etc.

[0019] Referring to Fig. Block 310 can include receiving a write operation of a data unit to an address on a logical volume. Block 315 can include identifying an entry in a basic volume table associated with the write address. Block 320 can include determining a current snapshot version number. Block 325 can include inserting the snapshot version number into the entry in the basic volume table.

[0020] In Fig. An example is shown where an initial write command 410 is received before the first snapshot of a data carrier is taken. In the Fig. In the example shown, a controller (e.g., the one in) receives... Fig. The storage controller shown (110) sends the first write command (410) to write the data unit "A" to an address "1" in a storage medium (e.g., the one in Fig. to write to the data carrier 150 shown. In response to the write command 410, the controller reads a data structure 420 for the current version to determine the current snapshot version "V1". The snapshot version "V1" can correspond to an initial (i.e., first in sequence) snapshot number and can indicate that the initial snapshot is still pending (i.e., has not yet been captured). Furthermore, the control unit accesses a base table 430 and identifies an entry indexed with the write address "1" (specified in the write command 410). The control unit then populates the identified entry in base table 430 with an indication or identifier of the current snapshot version (e.g., "V1" or "1").

[0021] The data structure 420 for the current version can generally be an example implementation of the version counter 166 (in Fig. (as shown). Furthermore, basic table 430 can generally correspond to an example implementation of basic table 162 (in Fig. (as shown). In some implementations, the base table 430 can contain multiple entries, each entry representing a different address on a data carrier (e.g., the one in Fig. The data volume shown (150) represents (or is indexed to). Furthermore, in some implementations, each entry in base table 430 may initially be empty (i.e., contain no data) and be populated with data when a data unit is written to the address represented by that entry. Additionally, in some implementations, each populated entry in base table 430 stores only an indication of a snapshot version (e.g., the current one (e.g., "V1" or "1")).

[0022] Referring again to Fig. Block 330 can involve storing the data unit at a physical location associated with the write address. Block 335 can involve padding an entry in a current version table with a pointer to the physical memory location. Block 340 can involve padding the entry in the current version table with a reference counter value of one.

[0023] For example, the control device stores the data unit “A” at memory location “05” in physical memory 450 (see Fig. Furthermore, the control unit accesses the V1 version table 440 (i.e., a version table associated with the current snapshot version "V1") and identifies entry "1" (i.e., the entry indexed with write address "1") in the V1 version table 440. The controller populates entry "1" of the V1 version table 440 with a pointer to physical location "05". As in Fig. As shown, the control unit also fills the entry “1” of the V1 version table 440 with the reference count value “1”.

[0024] The V1 version table 440 can generally be considered an example implementation of version table 164 (in Fig. (as represented). In some implementations, the V1 version table 440 can contain multiple entries, each representing a different address on a data carrier. Furthermore, in some implementations, each entry of the V1 version table 440 can initially be empty and be filled with data when a data unit is written to the address represented by that entry.

[0025] Referring again to Fig. Decision block 345 can include the determination of whether a trigger event for a snapshot has been detected. If the result is negative ("NO"), process 300 can return to block 310 (e.g., to continue receiving write operations for data units).

[0026] In Fig. An example is shown in which a second write command 412 is sent before the first snapshot is captured, but after the first write command 410 has been received (in Fig. is received (as shown). In which in Fig. In the example shown, the controller receives the second write command 412 to write data unit "B" to address "4" on the disk. In response to the second write command 412, the controller identifies entry "4" (i.e., the entry indexed to write address "4") in base table 430 and populates entry "4" of base table 430 with a reference to the current snapshot version "V1". The controller stores data unit "B" at position "03" in physical memory 450. Furthermore, the controller populates entry "4" of the V1 version table 440 with a pointer to physical memory location "03". As shown in Fig. As shown, the control device also fills the entry “4” of the V1 version table 440 with the reference count value “1”.

[0027] If decision block 345 determines that a trigger event for a snapshot has been detected ("YES"), process 300 can continue in block 350, including the creation of a snapshot table as a copy of the base disk table. Block 355 may involve incrementing the reference number by one for each entry in the current version table. Block 360 may involve incrementing the version number by one. Block 365 may involve creating a new version table associated with the incremented version number. After block 365, process 300 can return to block 310 (for example, to continue receiving write operations from data units).

[0028] In Fig. An example is shown in which a first snapshot trigger 414 is received after the second write command 412 is received (shown in Fig. is recognized. In the Fig. In the example shown, the controller detects the first snapshot trigger 414 and, in response, sets (e.g., increments) the current snapshot version to "V2" (e.g., in the current version data structure 420). The controller creates a V2 version table 442 (i.e., a version table associated with the current snapshot version "V2"). Furthermore, the controller creates the V1 snapshot table 432 by copying the current base table 430 (i.e., the base table 430 that exists during the copy operation).

[0029] As in Fig. As shown, entries "1" and "4" of the V1 snapshot table 432 are populated with the same snapshot version information (e.g., "V1") that was inserted into entries "1" and "4" of the base table 430 (i.e., in response to write commands 410 and 412). Since entry "1" of the V1 snapshot table 432 is now referenced by entries in both the base table 430 and the V1 snapshot table 432, the reference counter in entry "1" of the V1 version table 440 is set to "2" (i.e., incremented). Similarly, the reference counter in entry "4" of the V1 version table 440 is also set to "2".

[0030] In some implementations, the V1 snapshot table 432 can be a static data structure that duplicates the state of the base table 430 at a specific point in time (i.e., upon detection of the first snapshot trigger 414). The V1 snapshot table 432 can generally correspond to a sample implementation of snapshot table 163 (as in Fig. (as shown). Furthermore, the V2 version table 442 can generally be considered an example implementation of version table 164 (in Fig. (as shown) correspond. As in Fig. As shown, the V2 version table 442 can contain multiple entries, each representing a different address on a data carrier. In some implementations, each entry of the V2 version table 442 may initially be empty and be filled with data when a data unit is written to the address represented by that entry.

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

[0032] In Fig. An example is shown in which a third write command 416 is received after the first snapshot has been taken (e.g., as in Fig. (as shown). In the Fig. In the example shown, the control unit receives the third write command 416 to write the data unit "C" to an address "2" on the data carrier. In response to the third write command 416, the control unit reads the data structure 420 for the current version to determine the current snapshot version "V2". The control unit then populates entry "2" of the base table 430 with the current snapshot version "V2".

[0033] As in Fig. As shown, the control unit stores the data unit "C" at position "01" in physical memory 450. Furthermore, the control unit populates entry "2" of the V2 version table 442 with a pointer to physical memory location "01". The control unit also populates entry "2" of the V2 version table 442 with the reference counter equal to "1". In some implementations, the V1 snapshot table 432 is not updated to accommodate write commands received after the current snapshot version has been incremented to "V2".

[0034] In Fig. An example is shown in which a second snapshot trigger 417 occurs after receiving the third write command 416 (shown in Fig. ) is recognized. In which in Fig. In the example shown, the controller detects the second snapshot trigger 417 and, in response, sets (e.g., increments) the current snapshot version to "V3" (e.g., in the current version data structure 420). The controller creates a V3 version table 444 and generates the V2 snapshot table 434 by copying the current base table 430.

[0035] As in Fig. As shown, entries "1" and "4" of the V2 snapshot table 434 are populated with the same snapshot version information (i.e., "V1") that was inserted into entries "1" and "4" of the base table 430. Additionally, the reference numbers in entries "1" and "4" of the V1 version table 440 are set to "3" (i.e., incremented), indicating that these entries "1" and "4" are referenced by three different disk tables (i.e., the base table 430, the V1 snapshot table 432, and the V2 snapshot table 434). Furthermore, entry "2" of the V2 snapshot table 434 is populated with the same snapshot version information (i.e., "V2") that was also entered into entry "2" of the base table 430. Accordingly, the reference number in entry “2” of the V2 version table 442 is set to “2”, indicating that entry “2” is referenced by two different disk tables (i.e., by the base table 430 and the V2 snapshot table 434).

[0036] In Fig. An example is shown in which a fourth write command 418 is received after the second snapshot has been taken (e.g., as in Fig. (as shown). In the Fig. In the example shown, the control unit receives the fourth write command 418 to write the data unit "X" to address "5" on the storage medium. In response to the fourth write command 418, the control unit reads the data structure 420 for the current version to determine the current snapshot version "V3". The control unit then populates entry "5" of the base table 430 with an indication of the current snapshot version "V3". The control unit stores the data unit "X" at position "07" in physical memory 450. Additionally, the control unit populates entry "5" of the V3 version table 444 with a pointer to physical memory location "07". As in Fig. As shown, the control device also fills entry “5” of the V3 version table 444 with the reference count value “1”.

[0037] In Fig. An example is shown in which a fifth write command 419 is received after the fourth write command 418 has been received. In the Fig. In the example shown, the controller receives the fifth write command 419 to write the data unit "Y" to address "1" on the disk. Note that, as in Fig. As shown, the first write command 412 previously wrote the data unit "A" to address "1" on the storage medium. Accordingly, the fifth write command 419 causes the data unit "Y" to replace or overwrite the data unit "A" at address "1" of the storage medium.

[0038] In response to the fifth write command 419, the control unit reads the current version data structure 420 to determine the current snapshot version "V3". The control unit then overwrites the existing value of entry "1" in the base table 430 with the current snapshot version "V3". The control unit stores the data unit "Y" at position "02" in physical memory 450 and populates entry "1" of the V3 version table 444 with a pointer to physical position "02".

[0039] As in Fig. As shown, entry "1" in base table 430 refers to entry "1" in V3 version table 444. Accordingly, the control unit populates entry "1" in V3 version table 444 with the reference number "1," indicating that entry "1" in V3 version table 444 is referenced by a single volume table (i.e., base table 430). Furthermore, the controller modifies entry "1" in V1 version table 444 to reduce the reference number from "3" to "2," indicating that entry "1" in V1 version table 444 is now referenced by two different volume tables (i.e., V1 snapshot table 432 and V2 snapshot table 434).

[0040] Note that the data unit "A", which was previously written to address "1" (and has now been overwritten by the data unit "Y"), remains stored at location "05" of physical memory 450. Accordingly, the first snapshot (i.e., snapshot version "V1", recorded by the combination of V1 snapshot table 432 and V1 version table 440) still correctly references the stored data unit "A" and can therefore be used to restore or reconstruct the first snapshot. Similarly, the second snapshot (i.e., snapshot version "V2", recorded by the combination of V2 snapshot table 434 and V2 version table 442) also still correctly references the stored data unit "A" and can therefore be used to restore or reconstruct the second snapshot.

[0041] In Fig. An example is shown in which the stored data unit "B" is moved from memory location "03" to "06" (in physical memory 450). The move 460 can be caused, for example, by a defragmentation process of physical memory 450, a failure of a storage device contained in physical memory 450, etc. As shown in Fig. As shown, in response to shift 460, the control unit accesses entry "04" in the V1 version table 440 and replaces the pointer to memory location "03" with a pointer to memory location "06". Accordingly, shift 460 requires updating only a single version table (i.e., the V1 version table 440) and no changes to the disk tables (i.e., the base table 430, the V1 snapshot table 432, and the V2 snapshot table 434) or the remaining version tables (i.e., the V2 version table 442 and the V3 version table 444). In this way, some implementations can reduce the amount of processing and data transfer required to maintain accurate snapshots. Fig. 5 - Example process for reading snapshot data

[0042] Fig. Figure 500 shows an example process 500 for reading snapshot data in accordance with some implementations. For illustration, details of process 500 can be described below with reference to FIGS 1-4H, which show examples according to some implementations. However, other implementations are also possible. In some examples, process 500 can be implemented using the memory controller 110 (shown in FIGS 1-4H). Fig. Process 500 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions that can be executed by one or more processors). The machine-readable instructions can be stored on a non-transient, computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing machine, multiple processing machines, etc.

[0043] Block 510 can include receiving a read request for a data address in a snapshot version. Block 520 can include identifying a snapshot table associated with the specified snapshot version. Block 530 can include identifying a snapshot table entry in the snapshot table that is associated with the data address. Block 540 can include determining a snapshot version indicated by the snapshot table entry.

[0044] Block 550 can involve identifying a version table associated with the determined snapshot version. Block 560 can involve identifying a version table entry associated with the data address. Block 570 can involve reading a pointer to a physical memory location from the version table entry. Block 580 can involve reading a data unit stored in the physical memory location using the pointer.

[0045] For example, the control unit receives according to Fig. an initial query or request (in Fig. (not shown) to read address "1" recorded in snapshot version "V2". In response to the first query, the control unit accesses entry "1" of the 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 the V2 snapshot table 434. Furthermore, the control unit accesses entry "1" of the V1 version table 440 (i.e., the version table corresponding to the version identifier "V1") and reads pointer "05" stored in entry "1" of the V1 version table 440. The control unit then uses pointer "05" to read data unit "A" (stored at location "05" of physical memory 450) and returns data unit "A" as the result of the first query.

[0046] In another example, which still refers to Fig. When the control unit receives a second query or request (in Fig. (not shown) to read address "2" recorded in snapshot version "V2". In response to the second query, the control unit accesses entry "2" of the V2 snapshot table 434 and reads the version identifier "V2" stored in entry "2" of the V2 snapshot table 434. Furthermore, the control unit accesses entry "2" of the V2 version table 442 (i.e., the version table corresponding to version identifier "V2") and reads the pointer "01" stored in entry "2" of the V2 version table 442. The control unit then uses pointer "01" to read data unit "C" (stored at position "1" of physical memory 450) and returns data unit "C" as the result of the second query. Fig. 6 - Example procedure for the

[0047] Fig. Figure 600 shows an example procedure 600 for budget management in accordance with some implementations. For illustration, details of the 600 process can be described below with reference to FIGS 1-4H, which show examples of some implementations. However, other implementations are also possible. In some examples, the 600 process can be implemented using the 110 memory controller (shown in FIGS 1-4H). Fig. Process 600 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions that can be executed by one or more processors). The machine-readable instructions can be stored on a non-transient, computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing machine, multiple processing machines, etc.

[0048] Block 610 can include receiving a command to delete a specific snapshot version. Block 620 can include deleting the snapshot table associated with that specific snapshot version. For example, the control unit receives a command or request (in Fig. (not shown), to delete the snapshot version “V2” (see Fig. . In response to the command, the control unit deletes the snapshot table V2 434 (i.e., the snapshot table corresponding to the requested snapshot version “V2”).

[0049] Referring again to Fig. Block 630 can involve accessing the version table associated with the specific snapshot version. Block 640 can involve identifying a populated entry in the version table. Block 650 can involve decrementing the reference counter by one in the identified entry. For example, the control unit accesses version table V2 442 (i.e., the version table corresponding to snapshot version "V2") (see Fig. Furthermore, the control unit determines that entry “2” is the only filled entry in the V2 version table 442, and subsequently reduces the reference counter contained in entry “2” of the V2 version table 442.

[0050] Referring again to Fig. Decision block 660 may include determining whether the reference count value (decremented by one in block 650) is equal to zero. If the determination is positive ("YES"), process 600 may continue in block 670, including reading a pointer to a physical memory location in the identified entry. Block 680 may include deleting a data unit stored in the physical memory location using the pointer. Block 690 may include deleting the identified entry in the version table. For example, the control unit, with reference to Fig. The control unit checks whether the reference counter (contained in entry "2" of V2 version table 442) has a zero value. If so, the control unit reads the pointer "01" stored in entry "2" of V2 version table 442 and uses the pointer "01" to clear data unit "C" (stored at location "01" of physical memory 450). The control unit also clears or otherwise removes entry "2" of V2 version table 442.

[0051] Referring again to Fig. If, after block 690, decision block 660 determines that the reference number is not zero, process 600 can continue in decision block 695, including determining whether the version table has any remaining filled entries. If the determination is positive ("YES"), process 600 can return to block 640 (i.e., identify and process another filled entry in the version table). Otherwise, if decision block 695 determines that the version table has no remaining filled entries ("NO"), process 600 can terminate.

[0052] In some implementations, the housekeeping process 600 can use a reference counter (e.g., in entry "2" of version 442 of V2) to determine whether a stored data unit is no longer referenced by a snapshot and, if so, to release the storage space for other purposes. In this way, some implementations can enable efficient storage management without requiring multiple metadata structures to be loaded and parsed to identify obsolete data units. Consequently, some implementations can reduce the amount of processing and network resources required to manage stored data. Fig. 7 - Example of a data processing system

[0053] Fig. shows a schematic diagram of an example computer device 700. In some examples, the computer device 700 may generally represent part or all of the storage system 100 (shown in Fig. ). As shown, the computer device 700 can comprise a hardware processor 702, a memory 704, and a machine-readable memory 705 containing instructions 710-750. The machine-readable memory 705 can be a non-transferable medium. The instructions 710-750 can be executed by the hardware processor 702 or by a processing unit contained within the hardware processor 702.

[0054] Instruction 710 can be executed to receive a write of a first data unit to a first address on a disk. Instruction 720 can be executed to populate a first disk entry in a base data table with a reference to a first version table in response to receiving the write of the first data unit. For example, a controller receives (see Fig. The controller issues an initial write command 410 to write data unit "A" to address "1" on a storage medium. In response to write command 410, the controller reads a data structure 420 for the current version to determine the current snapshot version "V1". The controller then accesses a base table 430 and identifies an entry indexed with write address "1" (specified in write command 410). The controller then populates the identified entry in 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 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").

[0055] Instruction 730 can be executed to create a first snapshot table and a second version table in response to the detection of a snapshot trigger event, where the first snapshot table is a copy of the base disk table. For example, the controller detects (see Fig. The controller triggers the first snapshot trigger 414 and, in response, sets (e.g., increments) the current snapshot version to "V2" (e.g., in the current version data structure 420). The controller creates a V2 version table 442 (i.e., a version table associated with the current snapshot version "V2"). Furthermore, the controller creates the V1 snapshot table 432 by copying the current base table 430 (i.e., the base table 430 that exists during the copy operation).

[0056] Instruction 740 can be executed to receive a write command for a second data unit to a second address on the disk following the creation of the first snapshot table. Instruction 750 can be executed to populate a second disk entry in the base data table with a reference to a second version table in response to receiving the write command for the second data unit. For example, the control unit receives the third write command 416 to write data unit "C" to address "2" on the disk (see Fig. In response to the third write command 416, the control unit reads the data structure 420 for the current version to determine the current snapshot version "V2". The control unit then populates entry "2" of the base table 430 with the current snapshot version "V2". Furthermore, the control unit stores the data unit "C" at position "01" in physical memory 450 and populates entry "2" of the V2 version table 442 with a pointer to physical position "01". The control unit also populates entry "2" of the V2 version table 442 with the reference counter value "1". Fig. 8 - Example procedure for capturing snapshots

[0057] Fig. This shows an example process 800 for capturing snapshots in accordance with some implementations. In some examples, process 800 can be used with the memory controller 110 (shown in Fig. Process 800 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions that can be executed by one or more processors). The machine-readable instructions can be stored on a non-transient, computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing machine, multiple processing machines, etc.

[0058] Block 810 can include the receipt by a controller of a write operation of a first data unit to a first address on a disk. In response to receiving the write operation of the first data unit, block 820 can include the controller populating a first disk entry in a basic disk table with a reference to a first version table. In response to the detection of a snapshot trigger event, block 830 can include the controller creating a first snapshot table and a second version table, where the first snapshot table is a copy of the basic disk table.

[0059] Block 840 may involve the control unit receiving a write of a second data unit to a second address on the disk after the first snapshot table has been created. In response to receiving the write of the second data unit, block 820 may involve the control unit populating a second disk entry in the base data table with a reference to a second version table. Blocks 810-850 may generally correspond to the examples given above with reference to instructions 710-750 (shown in Fig. ) were described. Fig. 9 - Example of a machine-readable medium

[0060] Fig. Figure 900 shows a machine-readable medium that stores instructions 910-950, in accordance with some implementations. Instructions 910-950 can be executed by a single processor, multiple processors, a single processing machine, multiple processing machines, etc. The machine-readable medium 900 can be a non-transferable storage medium, such as an optical, semiconductor, or magnetic storage medium. Instructions 910-950 can generally correspond to the examples given above with reference to instructions 710-750 (in [reference to relevant section]). Fig. were described.

[0061] Instruction 910 can be executed to receive a write of a first data unit to a first address on a disk. Instruction 920 can be executed to populate a first disk entry in a base data table with a reference to a first version table in response to receiving the write of the first data unit. Instruction 930 can be executed to create a first snapshot table and a second version table in response to the detection of a snapshot trigger event, where the first snapshot table is a copy of the base disk table.

[0062] Instruction 940 can be executed to receive a write of a second data unit to a second address on the disk after the creation of the first snapshot table. Instruction 950 can be executed to populate a second disk entry in the base disk table with a reference to a second version table in response to receiving the write operation of the second data unit. conclusion

[0063] In accordance with the implementations described here, a storage system can use metadata structures that include a base disk table, snapshot tables, and version tables. When a data block is written to an address, the corresponding entry in the base disk table can be populated with a reference to a current version table. The corresponding entry in the version table can store a pointer to the physical location of the data block as well as a reference counter. To create a snapshot, the base disk can be copied to create a snapshot table, and a new version table can be initialized. The snapshot can be recorded by combining the snapshot table and the version table associated with the same snapshot version.If the physical location of the data block is subsequently changed, only the version table containing the pointer to the physical location needs to be updated. Accordingly, some implementations can reduce the amount of processing and data transfer required to accommodate changes to the physical locations of the stored data (e.g., compared to alternative approaches that require updating the physical location data in multiple metadata structures).

[0064] As above with reference to Fig. As explained, some implementations can use a reference counter (e.g., in entry "2" of V2 version table 442) to determine whether a stored data unit is no longer referenced by a snapshot and, if so, to release the storage space for other purposes. In this way, some implementations can enable efficient storage management without requiring multiple metadata structures to be loaded and parsed to identify obsolete data units. Consequently, some implementations can reduce the amount of processing and network resources required to manage the stored data.

[0065] Furthermore, in some implementations, metadata structures can be identified and accessed based on the snapshot version. Therefore, if it is necessary to update or access metadata for a specific period, the relevant metadata can be updated or accessed relatively easily, thus increasing the efficiency of metadata modifications or reads. Additionally, the metadata of stored data can be identified by the time period in which it was updated, rather than by the location where the data is stored. If a difference between two storage media needs to be determined, this difference can be established by comparing only the metadata of the media (i.e., without needing to access the respective physical storage space information).

[0066] Note that, while Fig. Various examples show that implementations are not limited in this respect. For example, the storage system can have 100, as in Fig. The diagram shows that additional devices and / or components, fewer components, different components, different arrangements, etc., may be included. Another example is that the functionality of the storage controller 110 described above may be contained in a different machine or software of the storage system 100. Other combinations and / or variations are also possible.

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

[0068] It should be noted that the instructions discussed above can be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed throughout a large system, potentially with multiple nodes. Such computer-readable or machine-readable storage medium or media are considered part of an item (or manufactured item). An item or manufactured item can refer to any single manufactured component or to multiple components. The storage medium or media can be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded for execution over a network.

[0069] The preceding description presents numerous details to facilitate an understanding of the topic disclosed herein. However, implementations without some of these details are also possible. Other implementations may include modifications and variations of the details described above. The attached claims are intended to cover such modifications and variations.

Images