KR20150075831A - Cache-enabled Metadata-aware Storage in Linux System - Google Patents

Abstract

A hybrid storage system according to the embodiment of the present invention includes a main processor, a main memory which loads a program or data according to the control of the main processor, a solid state drive on which a plurality of cache blocks are defined, and a hard disk on which the cache blocks are defined. The solid state drive is composed of a first region which stores a mapping table about a metadata block, a second region which stores the metadata block, and a third region which stores a caching mapping table for caching the data block.

Description

Cache-Enabled Metadata-aware Storage on Linux Systems -

The present invention relates to a hybrid storage system incorporating a fast SSD and a slow HDD to improve overall performance.

Hybrid storage systems integrate slower HDDs and faster SSDs to improve overall performance. To this end, various studies have been conducted on a method of using SSDs as a cache of HDDs.

One suggestion is to cache only metablocks. Since all IO requests are accompanied by a request for metadata blocks before making a request for data blocks. However, it evaluates that this approach does not meet the required performance improvement, so these results motivate the modification of the cache function integration approach.

When implementing the method proposed by the present invention in a Linux system, it was necessary to deal with various challenges, and the evaluation result of the proposed method showed at least 90% performance improvement over the conventional method. This result means that caching data blocks is much more impacting performance than metadata blocks.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and its object is to provide a hybrid storage for storing metadata in a solid state drive while data is being stored in a hard disk drive, To provide hybrid storage of Linux systems, which can improve performance by consolidating them.

According to an aspect of the present invention, there is provided a hybrid storage system including a main processor, a main memory loaded with data or a program under the control of the main processor, A hybrid storage system comprising a drive and a hard disk having a plurality of disk blocks defined therein, the solid state drive comprising: a first area for storing a mapping table for a metadata block; And a third area for storing the caching mapping table for caching the second area and the data block.

According to the hybrid storage system of the present invention, the MACSS is improved by adding an additional caching function to the original MACSS that only caches the metadata, so that the caching of the data block is added rather than the method of caching only the metadata block. have.

1 is a graph showing an average response time for an HDD and an average response time for a MACSS.
2 is a graph of results according to an embodiment of the present invention.
3 is an example of the pseudo code of the present invention.
FIG. 4 illustrates an average response time of a transaction according to an embodiment of the present invention. FIG.
5 is a graph showing time taken to copy files of different sizes according to an embodiment of the present invention;

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a preferred embodiment of the present invention will be described with reference to the accompanying drawings.

Hybrid storage, which combines cache with a hard disk drive and a small solid-state drive (SSD), will gain momentum before the hard disk drive is completely replaced by the SSD.

Some hybrid storage systems are configured using only software such as Dataplex and Hystor. On the other hand, hardware-based systems are also available.

Most research focuses on caching SSDs to HDDs because SSDs have constraints on the maximum allowable number of write operations and are less competitive than HDDs.

In particular, the block device layer of the operating system has been modified to handle a combined set of SSDs and HDDs as a single logical block device [9]. Then, using the internal cache manager, SSDs were used as read cache. On the other hand, the constraints on the write operation of the SSDs have made other efforts to reduce the number of write operations of the SSDs used in the cache. One such effort was to compress the data before writing to the SSDs. To this end, block based compression has been studied in comparison to file based compression.

While other schemes use SSDs as data caches, the meta-recognition combo storage system (MACSS) has been proposed to store metadata in SSDs.

Metadata is a record of information such as names of files, attributes, information such as location in storage, and available space in repository. It is noteworthy that MACSS only stores metadata in SSDs. The performance improvement due to MACSS is due to the fact that the operating system needs to access the metadata before requesting IO, otherwise the kernel can not find the file in storage.

Since the amount of metadata is relatively small compared to the amount of data, MACSS requires only small size SSDs to perform better than HDD dedicated systems.

However, when evaluating performance with other benchmarks, the performance of MACSS did not meet the target. MACSS used multiple virtual machine environments where 80% of the total IO requests were write requests, while the test was conducted using TPC-C [15], a standardized and widely used benchmark program. An in-depth analysis of this result shows that the percentage of IO requests for metadata is less than 3% of IO requests for data. Therefore, MACSS does not help to improve performance.

The present invention proposes to modify the MACSS to incorporate data caching for performance enhancement. One reason for consolidating data caching is that the volume of SSDs is cost-effective enough to store not only metadata but also data, as the cost per unit size of SSDs is substantially steadily decreasing. However, maintaining metadata with data caching is not straightforward. One of the differences between them is that while data caching is temporary, the recording of metadata should be permanent. The present invention introduces two sets of mapping information tables that manage metadata and data caches separately.

Assessment of MACSS

Because MACSS stores metadata in the SSD while data is stored on the HDD, it handles requests for data and IO requests for metadata differently. Therefore, MACSS requires hybrid storage consisting of SSDs and HDDs. According to the evaluation results, MACSS improved the response time by more than 35% compared to the HDD exclusive system. However, the results of evaluating MACSS using the benchmark program, TPC-C, are different. The TCP-C benchmark measures the average response time of five possible transaction types in an online commerce environment. The results show that the average response time of transactions has improved by only 17% over HDD dedicated systems, which is only half the required performance improvement. FIG. 1 shows the average response time of the HDD exclusive use and the MACSS. Rather than improvement, in the case of a delivery transaction, the response time is far less than the dedicated HDD. On the other hand, only the order status transaction achieved a performance improvement of more than 35%.

The inventor performed another experiment that could explain that the performance of the MACSS is lower than expected performance. Copying files of different sizes (100MB, 1GB, 2GB, 4GB) recorded the number of requests for IO requests for metadata or data. 2 shows that 18 metadata IO requests and 825 data IO requests are generated for a 100 MB file copy operation. It can be seen that the number of metadata IO requests is only about 2.1% of the number of data IO requests. This is similar for files of different sizes, with 3% for 1GB files, 2.8% for 2GB files, and 2.7% for 4GB files. It is clear that there is a big difference in the number of requests depending on the type, which means that quick access to metadata does not greatly improve overall performance. In addition, the fact that the price of an SSD is dropping lets you know that it is useful to cache data as well as metadata.

Integration of MACSS and caching and implementation on Linux systems

The inventor improves MACSS by adding a caching function. In addition to storing metadata, the SSD also acts as a cache that stores frequently accessed files.

Figure 3 shows the pseudo code of the proposed method. It checks whether the current request is a request for a metadata block or a request for a data block, and processes it accordingly. Then divide it by whether it is a request for reading or a request for writing.

In the case of a request for a data block, it operates as follows. If the target block is in the SSD, the request is provided by reading the block from the SSD. Otherwise (if the target block is not in the SSD), the target block is first read from the HDD and cached in the SSD for future access.

Similarly, in the case of writing, both cases must be handled. If the target block is cached, it overwrites the data in the HDD as well as the data in the SSD. Otherwise, it overwrites the data in the HDD and caches the data in the block of the SSD.

The proposed method needs to store additional information of SSD to provide cache function. To do this, the SSD is divided into three regions. The first area is an area for a mapping table for the metadata block. The first area stores a set of pairs of block numbers. Each pair corresponds to one metadata block and is composed of the HDD block number for the metadata block and the corresponding SSD block number. The second area stores a metadata block. The third area is an area for caching data blocks. This area also requires a mapping table between the HDD block number and the SSD block number. The present invention constructs and briefly discusses such mapping information in kernel memory.

Since there are two mapping tables in the proposed method, the metadata mapping table in the first domain is named MMT and the cache mapping table in the third domain is named CMT.

There are three problems to be addressed in implementing the proposed method in kernel version 2.6.32 and Linux systems.

The first is about how to distinguish whether a request is a metadata block or a data block, which requires knowledge of how the request is represented in the Linux system. The request is encapsulated into a structure called bio containing a set of member variables. One of the variables is called end_io as a pointer to a function that should be called when the corresponding request is completed. Since the function pointer differs depending on the block type, it is possible to know whether the request corresponds to a metadata block or a data block.

Second, the MMT stores the HDD and SSD block numbers as a pair of sets, each number having a length of 8 bytes. Since the pairs are sequentially stored in the MMT in the order of the HDD block number, the SSD block number Sn corresponding to the given HDD block number Hn is read by reading the SSD block at Hn / 32 and reading the offset at Hn% 32 + 16 .

Finally, the CMT is allocated in the memory of the device driver and has the same structure as the queue since the currently implemented cache replacement policy is LRU (Least Recently Used) method. Each element of the CMT is a pair of SSD block numbers associated with the HDD block number. Using LRU substitution, if there is a hit, the corresponding mapping element moves to the end of the queue, and if no more cache space is available, the element at the front of the queue is replaced with a new one.

Performance evaluation

The inventor uses the TPC-C benchmark as a parameter to use warehouse cardinality of 20, an area of 10, 300 customers, 100,000 items, 3000 orders, 100,000 shares and 900 new orders . The number of simultaneous connections, the number of terminals per warehouse, and selectivity are set to 20 respectively. The benchmark platform is shown in Table 1.

CPU Intel core i7-260, 2.40Hz Memory DDR3 16GB OS Linux Kernel Version 2.6.35 HDD WD 1200JS SSD 128 GB SATA2 interface

Figure 4 shows the average response time of a transaction. The proposed method dramatically improves response time compared to MACSS with the help of cache. In all transactions, response time decreased by more than 90%. This shows that the caching of data blocks has a far greater impact on performance than the way it caches only metadata blocks. Taking into account the fact that the metadata block itself is small enough to be cached inside the Linux system cache, it may be useless to cache metadata blocks in other locations.

Figure 5 shows the time taken to copy files of different sizes. Although the performance of the proposed method is similar to that of MACSS, it does not mean that the proposed method is not a better solution than MACSS. It should be noted that the proposed method has more overhead than MACSS because it has to deal with caching. Also, because the opportunity for cache hits is very low, copying may not take advantage of the cache. Despite these adverse conditions, the proposed method can match the performance of the MACSS. The proposed method means that the overhead due to the added caching function is included at a negligible level.

conclusion

The present invention proposes a method of improving MACSS by adding an additional caching function to an original MACSS that only caches metadata. The results of evaluating the MACSS using the TPC-C benchmark were not as good as previously thought. This implies that caching only metadata is not a suitable technique to take advantage of the maximum performance of the SSD. Beginning with this motive, the inventor designed and implemented MACSS with caching capabilities in a Linux system. The problem with the two mapping tables has been solved, and I have studied how to pull metadata requests from data requests in a Linux system. The evaluation results show that the proposed method improves the average response time by more than 90% of the MACSS, and the overhead due to the caching function is negligible.

The embodiments of the cache-based metadata-aware storage of the Linux system of the present invention described above are merely illustrative and those skilled in the art will appreciate that various modifications and equivalent implementations You can see that examples are possible. Therefore, it is to be understood that the present invention is not limited to the above-described embodiments. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims. It is also to be understood that the invention includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

Claims (3)

1. A hybrid storage system comprising: a main processor; a main memory loaded with data or programs under the control of the main processor; a solid state drive having a plurality of cache blocks defined therein; and a hard disk having a plurality of disk blocks defined therein ,
The solid state drive includes:
A first area for storing a mapping table for a metadata block;
A second area for storing a metadata block; And
And a third area for storing a caching mapping table for caching data blocks. 2. The method of claim 1,
Wherein a pair number is stored for the metadata block, and each pair comprises a hard disk block number and a solid state drive block number for one metadata block. The apparatus of claim 1, wherein the third region comprises:
And a caching mapping table between a hard disk block number and a solid state driver block number configured in the kernel memory.

Images