JP5591406B2 - Low latency content address storage device - Google Patents

Description

  The present invention relates to storing data in a content address storage device, and more particularly, storage between an application and the content address storage device to reduce latency associated with storing data in the content address storage device. Relates to arranging the layers.

  Content address storage (CAS) devices are more complex than traditional storage devices for writing data. Prior to confirming the synchronous write operation, the CAS device calculates a hash key based on the contents of the block and determines whether a block with the same content (as currently written content) has already been written to the CAS device ( For example, by performing a check to determine (by examining values in the hash table) and determining that the block is unique, the block is written. In a positive response, a content address equal to or derived from the hash key is also returned. The content address is used during a read operation to retrieve the block.

  In addition to checking to determine if a block with the same content has been previously stored, the calculation of the hash key is a significant factor in latency associated with writing data to the CAS device.

  In accordance with the principles of the present invention, a system for storing data in a storage device is provided. The system includes a content address storage device and a persistent cache. The persistent cache includes a temporary address generator that generates a temporary address corresponding to data stored in the persistent cache, stores the data in the persistent cache, and stores the data in the persistent cache as a temporary address. A non-content address storage device configured to search using. The persistent cache further includes an address translator configured to map a temporary address corresponding to the data in the non-content address storage device to a content address corresponding to the data in the content address storage device.

  In accordance with the principles of the present invention, a method for storing data in a storage device determines whether data corresponding to a write request should be stored in a non-content address storage device or written directly to a content address storage device. Including doing. When it is determined that the data is to be stored in the non-content address storage device, a temporary address of the data to be stored in the non-content address storage device is generated and the data is persistently stored in the non-content address storage device. A positive acknowledgment may be sent before the data is written to the content address store. In addition, at least one temporary address corresponding to data in the non-content address storage device is mapped to a content address in the content address storage device of the data after the data is written to the content address storage device.

  These and other features and advantages will become apparent from the following detailed description of the embodiments to be read in conjunction with the accompanying drawings.

1 is a block / flow diagram of a system for storing data in a content address storage device in accordance with the principles of the present invention. FIG. FIG. 2 is a block / flow diagram illustrating in more detail the system of FIG. 1 storing data in a content address storage device. FIG. 3 is a block / flow diagram of a method for storing data in a content address storage device in accordance with the principles of the present invention.

  The present disclosure provides a detailed description with reference to the figures in the following description of preferred embodiments.

  A storage system capable of reducing the latency associated with accessing a content address storage device will be described in accordance with the principles of the present invention. In this system, a storage layer consisting of a low latency block storage device (LLBS) is placed between a content address storage device (CABS) and an application that issues I / O operations according to an API that can refer to the content. ing. In addition to writing the block directly to the CABS, the block may first be written to the LLBS, acknowledged, and subsequently transferred to the CABS. At some point thereafter, these blocks may be removed from the LLBS. In doing so, the advantages of using a content address storage device (eg, elimination of redundant duplicate data) are maintained, while the disadvantages associated with writing to the content address storage device (eg, high latency) are eliminated, It is reduced.

  The LLBS may be a solid state drive device or a hard disk drive device for persistent storage. These devices are optimized to reduce the latency associated with I / O operations. In accordance with the principles described herein, LLBS stores data temporarily in an application so that the application does not experience the delays associated with computing a hash or retrieving a value in a hash table. Can return a positive response. An LLBS can also initiate a write to a CABS that contains the same data written to that LLBS. Writing to CABS encounters high latency due to the delays associated with computing the hash and retrieving values in the hash table. However, latency is not incurred by the application (or the end user using the application) because the LLBS can store the data quickly and return an acknowledgment.

  Embodiments described herein may be entirely hardware, or entirely software, or include both hardware and software elements. In preferred embodiments, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

  Embodiments are computer programs having program code that can be used by a computer or an instruction execution system or that can be accessed from a computer or computer-readable medium. Products may be included. A computer usable or computer readable medium includes any device that stores, communicates, propagates, or carries a program used by or in connection with an instruction execution system, apparatus, or device. It's okay. The medium can be a magnetic, optical, electronic, electromagnetic, infrared, or semiconductor system (or apparatus or system) or a propagation medium. The medium may be computer readable, such as semiconductor or solid state memory, magnetic tape, removable computer diskette, random access memory (RAM), read only memory (ROM), rigid magnetic disk, optical disk, etc. A storage medium may be included.

  A data processing system suitable for storing and / or executing program code may include at least one processor coupled directly to the memory elements or indirectly through a system bus. The memory element temporarily stores at least some program to reduce the number of times local code, mass storage, program code is retrieved from the mass storage device during execution. A cache memory may be included. Input / output or I / O devices and systems (including but not limited to keyboards, displays, pointing systems, etc.) may be connected directly or via an I / O controller intervening in the data processing system.

  A network adapter that allows a data processing system to become connected to other data processing systems, or remote printers, or storage devices, or storage systems via an intervening private or public network It may be connected to a processing system. Modems, cable modems, and Ethernet cards are only a few types of network adapters currently available.

  Referring now first to FIG. 1 of the drawings in which like numerals represent the same or similar elements, a block / flow diagram illustrates an exemplary system 100 for storing data in a content address storage device in accordance with the principles of the present invention. It shows. As shown in FIG. 1, the application 130 stores data in the storage system 110. Application 130 runs locally on a computer having storage system 110 or on a client machine connected to a server or other system having storage system 110 (eg, via a network). It may be executed.

  The storage system 110 has a low latency block storage (LLSB) 150 and a content address block storage (CABS) 160. CABS 160 represents any type of content address storage device. On the other hand, the LLBS 150 may include a solid state drive (SSD) or a hard disk drive (HDD) that is optimized to reduce latency associated with I / O operations. However, the LLBS 160 is not limited to these types of storage devices and may generally use non-content addressed storage media having a shorter latency than the CABS 160 for input / output (I / O) operations.

  The application 130 may store the data in the LLBS 150 first without storing the data directly in the CABS 160. If the data is successfully stored in the LLBS 150, an acknowledgment is returned to the application 130. Since the LLBS 150 is for low latency, the acknowledgment is returned relatively early or at least earlier than the time that the CABS 160 can return an acknowledgment.

  As will be appreciated, the content address storage application programming interface (API) allows communication between the application 130 and the LLBS 50 and between the LLBS 150 and the CABS 160.

  Turning to FIG. 2, a more detailed view of a system 200 for storing data in a content address storage device is illustratively depicted. Application 130 sends a write request to LLBS 150. Upon receipt of a write request from the application 130, the cache manager 210 sends a write request to the non-content address storage 235 configured as a key-value storage 230 that uses the storage 240 to persistently store data. There is. The cache manager 210 obtains a temporary address from the temporary address (“TA”) generator 250 in order to store the data from the write request in the non-content address storage device 235. This address is used as a key for later retrieval of data.

  The key-value storage unit 230 is responsible for controlling the mechanism for storing data in the storage device 240. The key-value storage unit 230 stores both the data and its temporary address in the storage device 240. The data can be retrieved later or retrieved using a temporary address. The storage device 240 is a short latency device such as a solid state drive (SSD), hard disk drive (HDD), or other device that has a latency lower than the CABS 160 for performing I / O operations. A system is preferred.

  Upon writing data to LLBS 150, cache manager 210 sends an acknowledgment to application 130 along with a temporary address that can be used to retrieve the data. The cache manager 210 also writes the data already written in the storage device 240 into the CABS 160. When storing data, the CABS 160 calculates a hash value based on the content of the data, and performs a de-duplication operation (for example, searching for a value in the hash table). Even though two identical blocks were written to LLBS 150, each with a separate temporary address, both of these blocks will eventually map to the same content address when LLBS 150 transfers data to CABS 160. Is done. Since the LLBS 150 has previously confirmed that the write operation has been successful, the application 130 retains the benefits of deduplication associated with storing data in the CABS 160 while maintaining these hashing and hash table lookup operations. The latency associated with can be avoided.

  After the data is successfully stored, the CABS 160 returns a content address reflecting where the data is stored in the CABS 160 to the cache manager 210 in the LLBS 150. The content address is sent to the address translator 220, which maps the temporary address (reflecting the location in the data LLBS 150) to the content address (reflecting the location in the data CABS 160) and this mapping. Is stored in the storage device 240. If the block has an embedded address, the data associated with each embedded address must first be written to CABS 160 and mapped to the corresponding content address before the parent block is written to CABS 160. This avoids the temporary address being written to the CABS 160.

  Once the address mapping is persistently written to the storage device 240, the LLBS 150 can delete the corresponding data in the storage device 240. When the application 130 issues a subsequent read request using a temporary address, the content address associated with the temporary address can be first retrieved by the address translator 220, and this information is retrieved from the CABS 160. Can be used to do.

  Although the data block can be removed from the LLBS 150 in the manner described above, removing the mapping of the temporary address to the content address may require cooperation of the application 130. Cooperation of application 130 is necessary to avoid situations where application 130 requests a block using its temporary address, but neither the block nor the mapping of temporary address to content address is available in LLBS 150. One way to avoid this situation is to have the application 130 periodically discard all of its addresses. Once this is done, the LLBS 150 can delete all of its mappings. After application 130 discards all of its addresses and LLBS 150 deletes all of its mappings, application 130 takes a read of a labeled block representing the root of the directed acyclic graph, here in its entirety by reference. The blocks can be accessed by issuing them in the manner described in US patent application 2010/0070698.

  Although data is typically stored in LLBS 150 before being transferred to CABS 160, there may be certain situations where it is desirable for data to be stored directly in CABS 160. For example, the application 130 issues a write request to the LLBS 150, but the LLBS 150 may not have enough space available for storing data. It may be advantageous to write incoming data blocks directly to CABS 160 rather than waiting for LLBS 150 to free up space by transferring data to CABS 160. This is just one exemplary situation where it may be preferable to store data directly into CABS 160, and there may be various other situations where data could be written directly into CABS 160. It should be noted that this is not possible.

  Since data is sometimes stored directly in the CABS 160, there may be situations where the LLBS 150 returns a content address to the application 130 instead of a temporary address. This can be processed by the application 130 without making the user aware of it. However, the LLBS 150 needs to be able to distinguish between a temporary address and a content address. This can be accomplished by reserving a bit in the address that indicates whether the address is a content address or a temporary address.

  Referring now to FIG. 3, a block / flow diagram illustrates a method for storing data in a content address storage system in accordance with the principles of the present invention. In block 310, application 130 issues a write request to store data in storage system 110. Storage system 110 may include a non-content address storage device (eg, LLBS 150) and CABS 160, as shown in FIGS.

  At block 320, upon receiving a write request, the LLBS 150 assigns a temporary address to the data. The temporary address is used to store data in the non-content address storage device 235 and to retrieve data in the non-content address storage device 235. Unlike content addresses later assigned by CABS 160, determining a temporary address for storing data does not involve computing a hash. In one embodiment, the temporary address may be generated by temporary address generator 250 in FIG. 2 and used by key-value store 230 to store data.

  Next, at block 330, the data that is the subject of the write request is stored in the LLBS 150 along with the temporary address assigned to the data block. There are various ways in which this information is stored. For example, in one embodiment, the non-content address storage device is configured as a key-value store, where the key is a temporary address and the value is the data content of the write request. Further, FIG. 2 discloses a single storage device 240 that stores both the temporary address to content address mapping and the data that can be retrieved by the temporary address. The mapping between the target address and the content address and the data that can be retrieved by the temporary address may be stored in separate storage devices.

  After the data from application 130 is stored in LLBS 150, LLBS 150 sends an acknowledgment to application 130 indicating that the data was successfully stored (block 340). The acknowledgment sent from LLBS 150 to application 130 also includes a temporary address associated with the data that enables application 130 to retrieve the data later. As explained above, the storage device 240 in the LLBS 150 has a relatively short latency for storing information when compared to the CABS 160. Because the LLBS 150 can store data in the storage device 240 and return an acknowledgment to the application 130 sooner than the CABS 160 would be able to do so, the latency encountered by the application 130 is reduced.

  Once the acknowledgment is sent to application 130, LLBS 150 then writes the data to CABS 160 at block 350. Once the data stored in LLBS 150 has been successfully copied to CABS 160, CABS 160 returns the content address to LLBS 150. The content address based on the content of the data block written to the CABS 150 indicates where in the CABS 160 the data has been written.

  As described above, storing data in a content address storage device (eg, CABS 160) involves high latency operations such as calculating a hash and performing a deduplication operation. However, by first storing the data in the LLBS 150 before transferring the data to the CABS 160, the application 130 does not have to wait for these long-latency operations to occur. Nevertheless, since the data is eventually transferred to the CABS 150, the application 130 can benefit from the deduplication operation performed by the CABS 160. Thus, the storage system 110 according to the present application allows the application 130 to take advantage of content address storage while eliminating (or at least reducing) the drawbacks of storing data in such a system. .

  After the data is stored in the CABS 160 and its content address is returned to the LLBS 150, the content address is mapped to a temporary address to the content address and the address translator 220 configured to store this information in the storage device 240. (Block 360). Upon storing the mapping information, data (currently stored in both LLBS 150 and CABS 160) may be deleted from LLBS 150 at block 370. If the application 130 wishes to read the data at some later time, the read request may include a temporary address for the data. Despite the data previously stored in LLBS 150 being deleted from LLBS 150, the temporary address may be used by address translator 220 to identify the corresponding content address in CABS 160 of the data. The data may then be read from CABS 160 using the content address.

  At block 380, address mapping on LLBS 150 (ie, mapping between temporary address and content address) is periodically deleted. This is an advantage because the size of the mapping stored in the LLBS 150 can be very large so that if it is not deleted, it can be used to store data This is because space is taken up in 240. However, before the mapping information can be deleted from the LLBS 150, the application 130 must discard the address (or at least the temporary address) stored by the application 130. This ensures that the application 130 does not issue a request for the data in the LLBS 150 (using the temporary address of the data) when neither the data itself nor the data mapping is stored in the LLBS 150. To do.

  There are various ways in which the application 130 can be ordered to discard the address. For example, in one embodiment, LLBS 150 may monitor the amount of mapping information that is being stored. Once the size of the mapping information exceeds a certain threshold, the LLBS 150 sends an “address discard signal” to the application 130 that tells the application 130 that the address information being stored by the application 130 should be discarded. Also good. After application 130 discards the address, an acknowledgment may be sent to LLBS 150 indicating that. Upon confirming that the address has been discarded by the application 130, the LLBS 150 can delete the map information stored in the storage device 240. Other ways of indicating that the address should be discarded by the application 130 are also conceivable.

  Although preferred embodiments of systems and methods for storing data in a content address storage device (these are intended to be illustrative and not limiting), various modifications and variations have been described. It should be noted that, in view of the above teachings, it can be made by those skilled in the art. Accordingly, it is to be understood that changes may be made in the particular embodiments disclosed which are within the scope of the invention as outlined by the appended claims. Having thus described aspects of the present invention with the details required by patent law, what is claimed and desired protected by Letters Patent is set forth in the appended claims.

Claims (14)

A content address storage device and a persistent cache;
The persistent cache is
A temporary address generator configured to generate a temporary address associated with data stored in the persistent cache;
A non-content address storage device configured to store data in the persistent cache using the temporary address and to retrieve data in the persistent cache;
An address translator configured to map a temporary address associated with data in the non-content address storage device to a content address associated with data in the content address storage device; The storage system is further configured to send a temporary address associated with the data to an application after the data is stored in the non-content address storage device .   The storage system of claim 1, further comprising a cache manager configured to write data stored in the non-content address storage device to the content address storage device.   The storage system of claim 2, wherein the cache manager is further configured to determine whether an address associated with a read request is a temporary address or a content address.   The system of claim 1, wherein data is deleted from the persistent cache after the data is written to the content address store, but the mapping between the temporary address and the content address is maintained. .   The storage system of claim 1, wherein the mapping between temporary addresses and content addresses is periodically deleted. 6. The storage system of claim 5 , wherein the mapping is deleted after the application discards all temporary addresses returned to it.   The storage system of claim 1, wherein the non-content address storage device comprises a solid state drive or a hard disk drive. A method for storing data in a storage system comprising:
Determine whether data corresponding to a write request is stored in a non-content address storage device or written directly to a content address storage device;
If it is determined to store the data in the non-content address storage device,
Generating a temporary address where the data is stored in the non-content address storage device;
Verify that the data was stored persistently in the non-content address storage device before the data was written to the content address storage device;
Send the application a temporary address associated with the data,
After the data is written to the content address storage device, at least one temporary address associated with the data in the non-content address storage device is mapped to the content address of the data in the content address storage device A method of storing data in a storage system. 9. The method of claim 8 , further comprising writing the data stored in the non-content address storage device to the content address storage device. The method of claim 8 , wherein the storage system is configured to determine whether an address associated with a read request is a temporary address or a content address. 9. The method of claim 8 , wherein data is deleted from the non-content address storage device after the data is written to the content address storage device, but the mapping between the temporary address and the content address is maintained. . 9. The method of claim 8 , wherein the mapping between temporary addresses and content addresses is periodically deleted. The mapping application deletes after discarding all temporary address back to it, the method of claim 1 2. 9. The method of claim 8 , wherein the non-content address storage device comprises a solid state drive or a hard disk drive.

Images