The efficiency of data de-duplication may be improved by storing related file data in a single container, or in multiple linked containers, of a history. Additionally, the efficiency of data de-duplication may be improved when shorter hash tables are used to reference historical data in a history. Shorter hash tables may be achieved by storing fewer than all the hash values obtained for a given amount of historical data. Further, the efficiency of data de-duplication may be improved by comparing related incoming file data with historical data from a container without hashing/chunking the remaining file data upon matching an earlier chunk of the incoming file data to the container.
|
11. A method for performing data de-duplication using deep packet inspection, the method comprising:
receiving file data carried by a data stream, the file data being associated with a common protocol;
partitioning a portion of the file data into a data chunk;
applying a hash algorithm to blocks within the data chunk to produce hash values;
matching at least some of the hash values to an entry in a hash table, the entry including a pointer indicating a segment of historical data stored in a container in a history;
reading all historical data from the container in the history without matching hash values to remaining segments of historical data in the container;
determining that the data chunk matches a segment of historical data from the container; and
comparing remaining portions of the file data with the remaining segments of historical data from the container.
1. A method for performing data de-duplication using deep packet inspection, the method comprising:
receiving file data carried by a data stream;
partitioning a portion of the file data into a data chunk;
applying a hash algorithm to data blocks within the data chunk to produce a set of hash values, the set of hash values including at least a first hash value and a second hash value;
selecting a subset of hash values from the set of hash values to store in a hash table, the subset of selected hash values including fewer than all hash values in the set of hash values, wherein the subset of selected hash values includes the first hash value and excludes the second hash value;
storing the portion of file data in a container in a history; and
storing the subset of selected hash values in the hash table without storing non-selected hash values in the hash table, wherein the first hash value is stored in the hash table and the second hash value is excluded from the hash table.
18. An apparatus for performing data de-duplication using deep packet inspection, the apparatus comprising:
a processor; and
a computer readable storage medium storing programming for execution by the processor, the programming including instructions to:
receive file data carried by a data stream;
partition a portion of the file data into a data chunk;
apply a hash algorithm to data blocks within the data chunk to produce a set of hash values, the set of hash values including at least a first hash value and a second hash value;
select a subset of hash values from the set of hash values to store in a hash table, the subset of selected hash values including fewer than all hash values in the set of hash values, wherein the subset of selected hash values includes the first hash value and excludes the second hash value;
store the portion of file data in a container in a history; and
store the subset of selected hash values in an entry of the hash table without storing non-selected hash values in the hash table, wherein the first hash value is stored in the hash table and the second hash value is excluded from the hash table.
6. A method for performing data de-duplication using deep packet inspection, the method comprising:
receiving initial file data carried by a data stream, the initial file data being associated with a common protocol;
storing, by a de-duplication module, all of the initial file data into a storage location such that all of the initial file data is concentrated into the storage location;
applying a hash algorithm to individual data blocks within the initial file data to produce at least a first hash value corresponding to a first data block in the initial file data and a second hash value corresponding to a second data block in the initial file data, wherein at least the first hash value is stored in a hash table;
receiving new file data, wherein hash values are obtained from the new file data;
matching the first hash value to one of the hash values obtained from the new file data without matching the second hash value to any of the hash values obtained from the new file data;
reading all of the initial file data from the storage location after matching the first hash value to a hash value obtained from the new file data, the second data block being read without matching the second hash value to any hash value obtained from the new file data; and
comparing portions of the initial file data with portions of the new file data.
20. An apparatus comprising:
a processor; and
a computer readable storage medium storing programming for execution by the processor, the programming including instructions to:
receive initial file data carried by a data stream, the initial file data being associated with a common protocol;
store, by a de-duplication module, all of the initial file data into a storage location such that all of the initial file data is concentrated into the storage location;
apply a hash algorithm to individual data blocks within the initial file data to produce at least a first hash value corresponding to a first data block in the initial file data and a second hash value corresponding to a second data block in the initial file data, wherein at least the first hash value is stored in a hash table;
receive new file data, wherein hash values are obtained from the new file data;
match the first hash value to one of the hash values obtained from the new file data without matching the second hash value to any of the hash values obtained from the new file data;
read all of the initial file data from the storage location after matching the first hash value to a hash value obtained from the new file data, the second data block being read without matching the second hash value to any hash value obtained from the new file data; and
compare portions of the initial file data with portions of the new file data.
2. The method of
3. The method of
4. The method of
storing a pointer reference and one or more offset indicators in an entry of the hash table, wherein the pointer reference identifies a location of the container in the history, and wherein the one or more offset identifiers indicate locations within the container of file data that produced the selected hash values.
5. The method of
8. The method of
determining that the history is nearing a threshold capacity; and
deleting historical data from the history by removing the single container from the history.
9. The method of
storing a first portion of the initial file data into a first linked container of the multiple linked containers;
determining that the first linked container lacks the required capacity to store remaining portions in the initial file data; and
storing at least some of the remaining portions of the initial file data in a second linked container in the multiple linked containers.
10. The method of
12. The method of
comparing the remaining portions of the file data with remaining segments of historical data from the container without applying the hash algorithm to the remaining portions of the file data.
13. The method of
comparing the remaining portions of the file data with the remaining segments of historical data from the container without partitioning the remaining portions of the file data into separate chunks.
14. The method of
determining that the file data matches the historical data from the container;
replacing the file data with a reference indicator to obtain a de-duplicated data stream; and
transmitting the de-duplicated data stream over a network.
15. The method of
16. The method of
aligning the data chunk with the segment of historical data; and
comparing the aligned data chunk and segment of historical data bit-by-bit.
17. The method of
identifying one or more blocks of the data chunk that produced the matching hash values;
identifying blocks of historical data in the segment of historical data in accordance with offset indicators; and
lining up the identified blocks of the data chunk with the identified blocks of the historical data.
19. The apparatus of
22. The apparatus of
remove the file data from the data stream;
apply a hashing algorithm to the file data to generate hash values;
store the file data in a history; and
store fewer than all of the hash values in a hash table.
23. The apparatus of
strip transport control protocol (TPC) headers off of packets transported in the data stream, thereby obtaining a contiguous string of payloads;
locate a leading network file system (NFS) header and a trailing NFS header in the contiguous string of payloads; and
place payload data located in-between leading NFS header and the trailing NFS header into an object.
|
The present invention relates generally to communications, and in particular embodiments, to efficient de-duplication using deep packet inspection.
Data de-duplication is a data compression technique for eliminating duplicate or repeating data from a data stream, and can be applied to network data transfers to reduce the number of bytes that must be sent. In the de-duplication process, unique chunks of data are identified and stored as historical data on both the transmit and receive sides of the network. Thereafter, incoming data is compared with the historical data on the transmit-side of the network, and when a redundant chunk is found, the redundant chunk is replaced with a reference indicator that points to the matching historical data. The receiver then uses the reference indicator to identify the matched historical data stored on the receiver side, which is used to replicate the duplicate data. Since the reference indicator is much smaller than the redundant chunk of data, and the same byte pattern may occur dozens, hundreds, or even thousands of times, the amount of data that must be stored or transferred can be greatly reduced.
The efficiency of a data de-duplication depends on a number of factors, including the algorithm used to store/match incoming data chunks with historical data. Conventional de-duplication techniques use a generic algorithm for all protocols, and hence the algorithm parameters are not tailored for specific protocols. Other factors include the length of the hash table, the length of the history, the size of the blocks used for generating hash values, etc. For instance, shorter hash tables generally allow for quicker searching, while longer histories typically allow for more frequent matching (since more historical data is available for de-duplication). Additionally, larger blocks provide for higher compression ratios (as larger for each matched blocks. However, smaller blocks provide for an increased likelihood that a match will be found. Other factors affecting the efficiency of data de-duplication include the amount of historical data stored in history, the method used for storing historical data, and the mechanism used to discard some of the old data to make room for newer data. New techniques and mechanisms for improving the efficiency of data de-duplication are desired.
Technical advantages are generally achieved, by embodiments of this disclosure which describe efficient de-duplication using deep packet inspection.
In accordance with an embodiment, a method for performing data de-duplication using deep packet inspection is provided. In this example, the method includes receiving file data carried by a data stream, partitioning a portion of file data into a data chunk, applying a hash algorithm to blocks within the data chunk to produce hash values. The method further includes selecting fewer than all of the hash values to store in a hash table, storing the portion of file data in a container in a history, and storing the selected hash values in an entry of the hash table without storing non-selected hash values in the hash table. An apparatus for performing this method is also provided.
In accordance with another embodiment, another method for performing data de-duplication using deep packet inspection is provided. In this example, the method includes receiving file data carried by a data stream, where the file data is associated with a common protocol. The method further includes partitioning the file data into a plurality of data chunks, identifying blocks of non-duplicate data within the data chunks, and storing all blocks of non-duplicate data into a single container such that all non-duplicate data within the data stream is concentrated in the single container. In alternative embodiments, the blocks of non-duplicate data may be stored into multiple linked containers such that all non-duplicate data within the data stream is concentrated in the multiple linked containers. An apparatus for performing this method is also provided.
In accordance with yet another embodiment, another method for performing data de-duplication using deep packet inspection is provided. In this example, the method includes receiving file data associated with a common protocol, partitioning a portion of the file data into a data chunk, applying a hash algorithm to blocks within the data chunk to produce hash values, and matching at least some of the hash values to an entry in a hash table. The entry includes a pointer indicating a container in a history. The method further includes reading all historical data from the container from the history, determining that the data chunk matches a segment of historical data from the container, and comparing remaining portions of the file data with remaining segments of historical data from the container. An apparatus for performing this method is also provided.
For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated. The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.
The making and using of embodiments of this disclosure are discussed in detail below. It should be appreciated, however, that the concepts disclosed herein can be embodied in a wide variety of specific contexts, and that the specific embodiments discussed herein are merely illustrative and do not serve to limit the scope of the claims. Further, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of this disclosure as defined by the appended claims.
Aspects of this disclosure provide techniques for improving the efficiency of data de-duplication. One aspect of this disclosure stores file data related to a common protocol in a single container (or in two or more linked containers), thereby allowing for more efficient de-duplication processing (as described in greater detail below). Another aspect of this disclosure provides shorter hash tables by storing fewer than all the hash values obtained for a given amount of historical data stored in history. Yet another aspect of this disclosure achieves more efficient de-duplication by comparing remaining portions of incoming file data (e.g., file data associated with the same object ID) with historical data from a container without hashing/chunking upon matching an earlier chunk of the incoming file data to historical data in the container.
Embodiments of this disclosure may be performed by a deep packet inspection (DPI) module and/or a de-duplication module. The DPI module may determine whether file data of an incoming data stream is associated with a known protocol. If so, the DPI module tags the file data with an object ID associated with the known protocol, and forwards the data stream to the de-duplication engine. The de-duplication engine may then separate file data related to the object ID into an object, and thereafter partition a first portion of the related file data into a first data chunk. The first data chunk is then divided into blocks, and hashed to produce a plurality of hash values. If one or more of the hash values match an entry in the hash table, then a corresponding container (as identified by the hash table entry) is read from the history, and the first data chunk is compared with the historical data of the container to determine if there is match. If some or all of the data chunk is matched to historical data in the container, then remaining portions of the incoming file data (e.g., file data associated with the common object ID) are compared with historical data in the container without chunking or hashing the incoming file data. Since the related historical data is stored in common containers, there is a relatively high probability that the remaining portions of the incoming file data will be successfully matched to historical data in the container after the earlier matched data chunk is confirmed.
Aspects of this disclosure provide at least the following six benefits: (I) Aspects of this disclosure reduce the hash table size by storing fewer than all of the hash values for a new data chunk. A smaller hash table allows for more efficient searching of the hash table, as well as allows for a given hash table to support a longer history. (II) Aspects of this disclosure allow for an entire object can to be recreated at the receiver-side of the network, thereby achieving a higher compression ratio; (III) Aspects of this disclosure allow for larger amounts of data (e.g., entire data chunks, or even objects) to be matched using fewer hash entries. (IV) Aspects of this disclosure reduce processing related to the chunking and hashing of incoming file data by comparing related file data directly to a container (e.g., without chunking or hashing the file data) upon matching a preceding chunk of the file data to historical data in the container; (V), Aspects of this disclosure reduce disk input/output delays by preloading linked containers when performing data de-duplication. For instance, a second linked container may be pre-loaded into memory while the first linked container is being compared to incoming file data. The container may be linked if the first linked container is filled before all related file data can be stored during an earlier storage operation; (VI) Aspects of this disclosure allow for more efficient removal of old/unused historical data from the history, as related file data is stored in a single container (or a chain of linked containers), which can be discarded in fewer read/delete operations.
Aspects of this disclosure may be performed by a deep packet inspection (DPI) module, which may be coupled to the data de-duplication engine on the transmit side of the network.
The DPI module 120 may inspect data carried in payloads of transport control protocol (TCP) packets. In some embodiments, the DPI module 120 may determine a type of protocol that is being used in the TCP session, such as a file transport protocol (FTP), system message block (SMB), network file system (NFS), and others. Thereafter, the DPI module 120 locates the start of an object within the TCP packet payloads. Locating the start of an object may be protocol dependent. For instance, if the TCP session is using FTP, the DPI module 120 may identify a start of file-contents when locating the start of the object. Alternatively, if the TCP session is using SMB, then the DPI module 120 may locate the start of the object in accordance with a file OPEN request/response. In any event, the DPI module 120 will group related file data in consecutive payloads, and associate that related file data with a common object ID. The object ID may be appended (or otherwise associated with) the related file data when the file data is forwarded to the de-duplication module 130.
The de-duplication module 130 may select a de-duplication algorithm for processing the file data based on the object ID. The de-duplication algorithm may specify various de-duplication parameters, including chunk size, block size, the number of hash values to store in the hash table (e.g., in the event that portions of the file data are not matched to historical data during de-duplication), conditions/mechanisms for removing old or seldom duplicated historical data, and others. After selecting the de-duplication algorithm, the de-duplication module 130 may separate a first portion of the file data into a first data chunk, divide the first data chunk into one or more blocks, and then apply a hash algorithm to the blocks to produce a plurality of hash values (e.g., a hash value for each block). The hash values will then be compared to entries in the hash table 132 to determine whether the object is a candidate for de-duplication.
If one or more of the hash values match a corresponding entry in the hash table 132, then a corresponding reference pointer and offset indicators of the matched entry will be used to identify a segment of historical data in the history 134. More specially, the reference pointer may be used to identify a container in the history 134 that stores, inter alia, the segment of historical data corresponding to the matched entry. Thereafter, the entire container will be read, and corresponding portions of the segment of historical data (as identified by the offset indicators) will be aligned to corresponding blocks of the first data chunk (e.g., the block producing the matched hash values) so that the first data chunk and the segment of historical data (e.g., corresponding to the matched entry) may be compared bit-by-bit.
If the chunks match, a reference indicator will be transmitted in liu of the file data. In some embodiments, remaining portions of the related file data (e.g., file data that was not included in the first data chunk) may be compared with historical data in the container without chunking or hashing. To wit, remaining file data that is associated with the same object ID as the first data chunk may be compared to the historical data (which has already been read into memory). This avoids wasting processing resources to chunk and hash the remaining file data, which is relatively likely to match historical data of the container (given that related historical data is stored in the same container or linked containers). In some embodiments, the container associated with the matched hash table entry may be linked to one or more other containers, as might be the case when related historical file data was too voluminous to fit in a single container during the earlier storage procedure. In such cases, the other linked container may be pre-loaded into memory when the remaining file data is being compared to historical data in the container associated with the matched hash table entry. A hash table entry may include various information, such as a hash value, a container number, one or more offset indicators, the size of the block, etc.
If hash values are not found in the hash table 132, then the first data chunk may be stored in the history 134, and a corresponding entry may be made in the hash table 132. More specifically, fewer than all of the hash values produced for the data chunk are selected for storing in the hash table 132. The remaining data chunks (e.g., subsequent data chunks associated with the same object or protocol as the first data chunk) may be processed. If those chunks are not de-duplicated, then they may be stored in the same container as the first data chunk. When space or circumstances do not allow all the related chunks to be stored in a common container, the related chunks may be stored in different containers that are linked (or otherwise associated with) one another, e.g., in the hash table 132 or otherwise.
Conventional data de-duplication networks may lack the DPI module 120, and instead rely solely on the de-duplication modules 130, 150 to perform data de-duplication.
Efficiency of the conventional data de-duplication procedure 200 is limited by the size of the blocks 210-240, the size of the hash table 132, and the length of the history 134. To wit, the probability of finding a match is increased when the blocks 210-240 are shorter and/or when the history 134 is longer. However, when the blocks 210-240 are short, the hash table 132 becomes longer, as more hash values are generated for same length history 134. Aspects of this disclosure store fewer than all of the hash values derived from a given chunk/object in the hash table, thereby allowing a smaller hash table to represent a longer history.
If the hash values do not match an entry in the hash table, then the method 500 proceeds to step 540, where the de-duplication module stores the data chunk in history. Thereafter, the method 500 proceeds to the step 545, where the de-duplication module selects fewer than all of the hash values obtained during step 530 to store in the hash table. The hash values may be selected in accordance with an algorithm, e.g., highest N hash values (N is an integer), etc. Next, the method 500 proceeds to the step 550, where the de-duplication module stores the selected hash values in a new entry in the hash table. Thereafter, the method 500 proceeds to the step 555, where de-duplication module determines whether more related file data needs to be processed (e.g., whether more file data exists in the object). If not, then the method 500 proceeds to the step 595, where the data stream is transmitted over the network. If there is more file data to be processed, the method 500 proceeds to the step 560, where the de-duplication module places the next portion of the file data into data chunk. Next, the method 500 proceeds to the step 565, where the de-duplication module divides the data chunk into blocks, and applies a hashing algorithm to the blocks to obtain a plurality of hash values. Thereafter, the method 500 proceeds to the step 565, where the de-duplication module compares the hash values to entries in the hash table to determine whether the hash values match one of the entries. If the hash values do not match an entry in the hash table, then the method 500 reverts back to step 540
If the hash values match an entry in the hash table, then the method 500 proceeds to step 580, where the de-duplication module obtains a reference pointer from the matching entry. Thereafter, the method 500 proceeds to the step 585, where the de-duplication module reads the container from history as indicated by the reference pointer. Next, the method 500 proceeds to the step 590, where the de-duplication module compares the data chunk with the historical data in the container to see if there is a match. If not, the method 500 proceeds to step 540. If the chunk matches historical data in the container, then the method 500 proceeds to step 591, where the de-duplication module compares remaining portions of the file data to historical data in the container without chunking or hashing the remaining portions of file data. Next, the method 500 proceeds to step 592, where the de-duplication module replaces matching portions of the file data with reference indicators in data stream. Thereafter, the method 500 proceeds to step 555.
In some embodiments, portions of incoming file data from the same object may be stored in the same container in history.
In some embodiments, the DPI module 700 may perform additional processing (e.g., processing not explicitly shown in
After a match is found and the container storing the matching historical data is read, the bytes ahead of the matched block within the incoming contents are compared with the data above the matched block of historical data. Similarly the trailing data after the matched blocks is also compared to find a bigger match between the incoming stream and the container retrieved from the history. A lightweight check sum is computed for the matched sequence for the receiving side to confirm the match. If the de-duplication implements location based reference, the matched container ID, the offset and the matched portion along with the checksum is used as reference. On the other hand, if content based reference is used, the hash value of the matched fingerprint, the size and offset of the fingerprinted block within the matched sequence, the size of the matched sequence, and the checksum of the matched sequence are used for reference. A copy of the unmatched data (before, after, and/or in between matched portions) is stored in the history in accordance with a scheme. One such scheme is, if the unmatched portion includes one or more fingerprinted blocks, selecting one or more representative fingerprints from the list. One method of selection is picking the one with largest fingerprint value, or the one with for a block with close to optimum size (say average of minimum and maximum acceptable block sizes). If the incoming data stream is the first segment of a newly identified object, allocate a new chunk, and initialize the chunk header with the newly arrived object ID. If the incoming data is in the mid-stream of an object and a chunk is already been in used for the object and the chunk is in memory and the chunk has enough free space to store the unmatched portion of the data, the unmatched potion is copied into the chunk at the end of the used space. The selected fingerprint or fingerprints are added into the hash table along with their sizes and the offsets (of the finger printed blocks) within the chunk. If the current allocated chunk does not have enough space, a new chunk is allocated and the filled chunks header is updated with chunk number of the newer one as a link associated with the same object.
When the history reaches a capacity threshold, an algorithm (e.g., least recently used (LRU), etc.) is used to find the oldest unused container of historical data to be discarded. All the hash table entries that point to the freed container are also discarded. If the selected chunk is part of an object that spans multiple containers, all those linked containers are also discarded. After the new file data is stored in history, the unmatched portions of the file data are forwarded along with the references. Depending on how the de-duplication is implemented the reference could be either the location within the container or the hash of the contents. In reality, to facilitate the data travelling in reverse direction, the computed fingerprints are also included in the reference even when the implementation uses absolute location of the data within the history. This way, the receiving side can build its own hash table without actually finding blocks and computing hashes.
Various wire formats may be used to forward the data from the DPI module to the de-duplication module.
The references are indicated by the leading 2 bits of the two bytes set to 10 and 11. The remaining 14 bits provide the size of the matched segment. A value of 10 is used for the bits to provide the location based reference, which simply includes the container number (2 bytes) and offset (2 bytes). When the bits value is 11, the reference is content based, the information provided here is a hash value (4 bytes), hash size (2 bytes), hash offset (2 bytes) within the matched data segment, and the checksum (2 bytes) of the data segment.
In both sending and receiving side, when an incoming data segment is identified as part of an object and the container retrieved for the matched data includes an object ID and a link to the next container with the same object ID, the linked container is also read in advance to facilitate the matching of the subsequent incoming data stream belonging to the same object.
Some aspects of this disclosure have been described as being performed by the DPI module, while other aspects of this disclosure have been described as being performed by the de-duplication module. However, the de-duplication module may be configured to perform some (or all) of the aspects described as being performed by the DPI module, and vice-versa. Further, the DPI module and the de-duplication module may be a common device/module in some implementations.
Although the description has been described in detail, it should be understood that various changes, substitutions and alterations can be made without departing from the spirit and scope of this disclosure as defined by the appended claims. Moreover, the scope of the disclosure is not intended to be limited to the particular embodiments described herein, as one of ordinary skill in the art will readily appreciate from this disclosure that processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, may perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
Patent | Priority | Assignee | Title |
10224957, | Nov 27 2017 | Intel Corporation | Hash-based data matching enhanced with backward matching for data compression |
10346074, | Nov 22 2015 | SYNAMEDIA LIMITED | Method of compressing parity data upon writing |
Patent | Priority | Assignee | Title |
20100250896, | |||
20110016095, | |||
20120030477, | |||
WO2012092212, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 28 2012 | Futurewei Technologies, Inc. | (assignment on the face of the patent) | ||||
Jan 15 2013 | DAS, KALYAN | FUTUREWEI TECHNOLOGIES, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 029728 | 0742 |
Date | Maintenance Fee Events |
Jul 26 2018 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jul 27 2022 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Date | Maintenance Schedule |
Feb 10 2018 | 4 years fee payment window open |
Aug 10 2018 | 6 months grace period start (w surcharge) |
Feb 10 2019 | patent expiry (for year 4) |
Feb 10 2021 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 10 2022 | 8 years fee payment window open |
Aug 10 2022 | 6 months grace period start (w surcharge) |
Feb 10 2023 | patent expiry (for year 8) |
Feb 10 2025 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 10 2026 | 12 years fee payment window open |
Aug 10 2026 | 6 months grace period start (w surcharge) |
Feb 10 2027 | patent expiry (for year 12) |
Feb 10 2029 | 2 years to revive unintentionally abandoned end. (for year 12) |