CN109840247B - File system and data layout method - Google Patents

Abstract

The invention provides a file system. The file system includes a cost calculation module and an area division module. The cost calculation module is used to calculate or estimate the access cost of a file request in the file system. The cost calculation module can output a cost model to the area division module; The division module is used to divide the file into different areas so as to minimize the total cost of a given access; the area division module is also used to obtain the strip size corresponding to the area. The present invention also provides a data layout method. Compared with the prior art, the beneficial effects of the present invention are: the file system supports the data layout of the region level by dividing the file into a group of optimal regions, and the file system can determine the optimal region and the corresponding strip size Therefore, the file system can optimize the data layout of the hybrid storage system, and further, the file system can flexibly adapt to changes in workload and heterogeneity of the storage system, and can significantly speed up the performance of the I/O system.

Description

File system and data layout method

technical field

The invention belongs to the technical field of data layout, and in particular relates to a file system and a data layout method.

Background technique

As large-scale data-intensive applications continue to increase in various application fields, I/O (input/output) performance is becoming the bottleneck of storage systems. In order to solve this problem, those skilled in the art have successively introduced many parallel file systems (Parallel File Systems, PFS for short) into high-performance storage systems. The above-mentioned parallel file systems include OrangeFS, Lustre, GPFS, PanFS and PLFS, etc. The introduction of each parallel file system is as follows:

1. OrangeFS is a branch of the Virtual Parallel File System (PVFS). Similar to PVFS, it is a parallel file system proposed for high-performance computing and high-performance data access. Compared with traditional PVFS, Ora-ngeFS is committed to improving the performance of small file processing, increasing the cross fault tolerance of servers and providing secure access control.

2. Lustre is a Linux cluster parallel file system developed by HP, Intel, Cluster File System and the US Department of Energy. Lustre uses a distributed lock management mechanism to achieve concurrency control, and the communication links of metadata and file data are managed separately.

3. GPFS is the abbreviation of General Parallel File System. GPFS from IBM is a scalable, high-performance, general-purpose parallel file system based on shared disks. GPFS can provide parallel, high-speed, safe, and reliable data access for all nodes in the storage system.

4. PanFS is a parallel file system developed by Panasas. PanFS is a general parallel file system. At present, its main application areas are similar to those of luster. PanFS is scalable and can provide strong consistency through distributed locks.

5. PLFS is an open source parallel checkpoint storage file system.

In summary, based on these parallel file systems, the operation of distributing data files across multiple servers can be performed. Therefore, a parallel file system (PFS) can allow multiple tasks of parallel applications to synchronously access data files in the form of aggregated I/O bandwidth.

However, the existing parallel file system (PFS) is not without defects. The defect is that the existing parallel file system (PFS) does not match with the hybrid storage system based on the new storage technology. Before gradually describing the incompatibility problem, it is necessary to clarify the situation of hybrid storage systems based on new storage technologies. Compared with Hard Disk Drive (HDD), solid-state drive has the characteristics of high storage efficiency, fast response and high cost. Therefore, comprehensive consideration, a reasonable storage system is not suitable for all hard disk drives, because Read and write and response speeds are slow, and reasonable storage systems are not suitable for all solid-state drives, which are expensive to manufacture. In other words, solid-state drives will not completely replace hard disk drives in a large cluster. Therefore, using a hybrid storage system that includes both solid-state drive-based servers and hard-disk drive-based servers is a preferred strategy. This strategy is more practical for HPC systems with limited cost budgets. HPC is the abbreviation of High Performance Computing (High Performance Computing) cluster.

On the other hand, the efficiency of a parallel file system (PFS) depends on the efficient data file layout, i.e. how the data files are distributed across the available nodes, most existing layout schemes use fixed-size stripes split into multiple servers for distribution Data files also utilize fixed-size stripes to provide concurrent data access from multiple servers, which even enables data placement on each server. Although the existing layout scheme is simple to implement and easy to be widely used, such a layout scheme is obviously suitable for storage systems using homogeneous servers, not for hybrid storage systems.

When existing parallel file systems are applied to a hybrid storage system, the performance gap between solid-state drive-based servers and hard drive-based servers can significantly degrade parallel file system performance, as solid-state drive-based servers are always more HDD-based servers have higher performance and thus require less I/O time to complete the same amount of data access, which, if applied with the existing layout scheme, gives solid-state drive-based servers and HDD-based servers Allocate the same stripes, which can cause severe load imbalance among heterogeneous servers, and complex I/O workloads can jeopardize the efficiency of the I/O system.

SUMMARY OF THE INVENTION

In view of this, in order to solve the problem of unreasonable data distribution when the existing parallel file system (PFS) is matched with a hybrid storage system based on a new storage technology, the present invention provides a file system, the file system includes: The I/O tracer, the cost calculation module and the area division module are electrically connected to each other, the I/O tracer is used to provide the area division module with the I/O information collected by itself when the file system is running The I/O tracer is also used to provide the configuration file of the file system collected by itself to the cost calculation module; the cost calculation module is used to calculate or estimate the file request in the file system. access cost, so as to output the cost model to the area division module; the area division module is used to generate a distribution area that minimizes the total cost according to the cost model, and divide the file into different areas, the area division module It is also used to obtain the strip size corresponding to the region.

Preferably, the file system further includes a kernel part, and the kernel part is used for executing the interaction of information or data among the metadata server, the hybrid storage system and the client; the kernel part includes a FUSE module.

Preferably, the file system further includes a daemon process module, and the daemon process module is used to execute the daemon process in the background; the FUSE module is used to act as an agent of the daemon process.

Preferably, the file system further includes an update data layout module, which is respectively connected with the daemon process module, the I/O tracer, the area division module and the hybrid storage system. connected, the update data layout module is used to dynamically detect and update area changes.

Preferably, the cost calculation module is used to calculate the total cost of the request, and the total cost calculation formula is: T=T _s +T _c +T ₂ , in the formula, T _s represents the FUSE module and the daemon process module The time between two context switches, T _c represents the replication time, and T ₂ represents the network and storage cost.

Preferably, the hybrid storage system includes a server SServer based on a solid state drive and a server HServer based on a hard disk drive;

The calculation formula of the copy time is: T _c (r,h,s)≈3(mh+ns)t _c , in the formula, t _c represents the unit data copy time from the kernel space to the user space, and h represents the HServer uploading time. Band size, s represents the strip size on the SServer, m represents the number of HServers, and n represents the number of SServers;

The calculation formula of the network and storage cost is: T ₂ ≈T _e +max{h(t _h +t),s(t _s +t)}, in the formula, t represents the data transmission network time, t _h and t _s represents the unit data transmission time on the HServer and the unit data transmission time on the SServer, respectively, and T _e represents the network connection time.

所述最小成本

的计算公式为：Preferably, the area division module is used to obtain the minimum cost of dividing l events into k areas starting from event i.

the minimum cost

The calculation formula is:

定义了一个大小为

区域，

表示尺寸为f的第一区域的成本。formula,

defines a size of

area,

represents the cost of the first region of size f.

条带化，并分别得到h_i和s_i，s_i的计算公式为s_i＝αh_i，h_i的计算公式为：Preferably, solid-state drive-based servers and hard-disk drive-based servers are capable of

Striping, and obtain hi and s _i respectively, the calculation formula of s _i is s _i = _{αhi ,} and the calculation formula of _hi is:

In the formula, α≥1 and is the expansion factor of SServer relative to HServer, and B represents the block size in the configuration.

The present invention also provides a data layout method, which includes:

In step S1, the I/O information of the data access at runtime and the file system configuration file used for cost modeling are collected into the tracking file, the file system configuration file is directed to establish the cost model, and the I/O information is used for the cost modeling. regional division;

Step S2, calculate or estimate the access cost of the file request to form a cost model;

Step S3, according to the cost model to generate a distribution area where the total cost is minimized, and divide the file into different areas;

Step S4, acquiring the strip size corresponding to the area.

The beneficial effects that the embodiment of the present invention has compared with the prior art are:

The file system proposed by the present invention supports the data layout of the region level by dividing the file into a group of optimal regions, and the optimal region and its stripe size can be determined through the file system. Therefore, through the file system The data layout of the hybrid storage system 100 can be optimized. The file system can flexibly adapt to workload changes and server heterogeneity, resulting in significantly faster I/O system performance.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present invention more clearly, the following briefly introduces the accompanying drawings that need to be used in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only for the present invention. In some embodiments, for those of ordinary skill in the art, other drawings can also be obtained according to these drawings without any creative effort.

1 is a schematic diagram of a data layout scheme using a fixed-size strip in the prior art;

Fig. 2 is a schematic diagram of a data layout scheme based on regional division;

Fig. 3 is the schematic diagram of the file system based on regional data layout;

4 is a schematic diagram of a working principle of a cost calculation module in an embodiment of the present invention;

FIG. 5 is a diagram of an example application of a file system in an embodiment of the present invention.

Detailed ways

The above and other technical features and advantages of the present invention will be described in more detail below with reference to the accompanying drawings.

In the description of the present invention, it should be understood that the terms "first" and "second" are only used for description purposes, and cannot be interpreted as indicating or implying relative importance or the number of indicated technical features. Thus, a feature delimited with "first", "second" may expressly or implicitly include at least one of that feature. In the description of the present invention, "plurality" means at least two unless expressly and specifically defined otherwise.

In the present invention, unless otherwise expressly specified and limited, the terms "installed", "connected", "connected", "fixed" and other terms should be understood in a broad sense, for example, it may be a fixed connection or a detachable connection , or integrated; it can be a mechanical connection or an electrical connection or can communicate with each other; it can be directly connected or indirectly connected through an intermediate medium, it can be the internal connection of two components or the interaction relationship between the two components, unless otherwise expressly qualified. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific situations.

In the description of this specification, description with reference to the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples", etc., mean specific features described in connection with the embodiment or example , structure, material or feature is included in at least one embodiment or example of the present invention.

In the following description, for the purpose of illustration rather than limitation, specific details such as specific system structures and technologies are set forth in order to provide a thorough understanding of the embodiments of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine the different embodiments or examples described in this specification, as well as the features of the different embodiments or examples, without conflicting each other.

In order to illustrate the technical solutions of the present invention, the following specific embodiments are used for description.

Example

In general, most PFSs employ three typical data layouts: 1-DH, 1-DV, and 2-D. The 1-DH layout means that one client process can access data from all storage servers. In contrast to the 1-DH layout, the 1-DV layout means that a client process can only access data from a single storage server. The 2-D layout is between the 1-DH layout and the 1-DV layout, which means that the 2-D layout means that a client process accesses data from a subset of all storage servers.

First, compare the difference between the data layout of most PFS and the data layout of the regional file system. Take the example of executing two concurrent reads to access a 9x size file. Two concurrent reads are defined as the first read. 71 and the second read 72. The first reading 71 and the second reading 72 are read according to the time axis 73 .

When using the data layout of a traditional file system, as shown in Figure 1, files are evenly partitioned and stored on each storage server with a stripe size of 3x. So when the three servers complete at the same time, each request takes 3x the time to complete, and the two read requests take a total of 6x to complete. This data layout ignores the differences between different storage media in the hybrid storage system, so that the read/write efficiency of the higher-performance storage media cannot be fully reflected. It can be understood that the higher-performance storage media is forced to be degraded.

As shown in Figure 2, for the regional file system, its data layout scheme has obvious advantages. The regional file system RLFS divides the file 7 into two areas, the two areas are the first area 73 and the second area. 74. Each region is partitioned on all servers using its own corresponding stripe size (x or 2x). The second read 72 will be divided into two parts to read, and the total time corresponds to reading 3x (3x=x +2x) time, but in terms of the time of the second read 72, the two types of data involved in the comparison are laid out in the same way, but the time of the first read 71 based on the zone-level file system is reduced to the time required to read 2x.

From this example, it can be found that the region scheme in RLFS is a finer-grained and more adaptive data layout scheme than the traditional data layout scheme, which corresponds to different stripe sizes in all storage servers. Therefore, the zone scheme in RLFS can be seen as a variant of the 1-DH layout scheme, RLFS is able to aggregate the bandwidth of all storage servers to maximize I/O performance. RLFS is a good match for the hybrid storage system 100 .

RLFS is designed to support region-based data layout by using file strips of different sizes. To accommodate mixed storage systems 100 and complex I/O workloads at the same time, RLFS employs a partitioning approach to achieve optimal data layout. A cost model is generated in RLFS. According to the cost model, RLFS divides a large file into a set of regions, and each region stores its own stripe size separately. The optimal regions and their stripe sizes are obtained when the total cost of all I/O requests of the application is minimized.

The storage system involved in this embodiment is a hybrid storage system 100. The hybrid storage system 100 includes a solid-state drive-based server 102 and a hard disk drive-based server 101. The solid-state drive-based server is referred to as SServer for short, and the hard disk drive-based server HServer.

An embodiment of the present invention provides a file system, which is called a region-level file system, that is, a Region Level File System, or RLFS for short. The file system can support region-level data layout and solve the data distribution problems that occur in existing parallel file systems. RLFS relies on a defined cost model and a per-zone-based heterogeneous-aware scheme to determine the optimal file stripe size for each server, and further leverages changing access patterns to tune the zone scheme at runtime.

More specifically, a cost model is first developed for RLFS to estimate the completion time of region accesses, thereby utilizing dynamic programming to partition files into fine-grained regions, and then for HDD and SSD servers, the optimal file stripes selected for each region are allocated. size. RLFS is storage system and application aware. RLFS essentially represents a change from the traditional one-dimensional fixed stripe size layout to two-dimensional changing stripe size layout. RLFS can well adapt to changes in server performance and application behavior. Variety. In addition, RLFS also updates the generated data layout scheme based on the detected changes in access patterns to address static data layout issues and make them more suitable for runtime file access.

As shown in FIG. 3 , an embodiment of the present invention provides a file system, which is called a region-level file system, that is, a Region Level File System, or RLFS for short. The file system can support region-level data layout and solve the data distribution problems that occur in existing parallel file systems.

The RLFS package includes the kernel part and the user-level daemon module 20 , preferably, the kernel part includes the FUSE module 10 . In other words, a file system RLFS provided by the embodiment of the present invention is preferably designed based on the FUSE framework. FUSE refers to a user space file system, which is an abbreviation for Filesystem in Userspace. The kernel part is preferably a Linux kernel module, and the kernel part further includes a VFS module 11 . VFS is a virtual file system, which is an abbreviation for Virtual File System. The VFS module 11 is used to register RLFS, a block device will be created in the kernel part, the block device acts as the interface between the daemon process module 20 and the kernel part, the FUSE module 10 acts as an agent of the daemon process module 20, and is used for various file systems issued by the application program. ask.

Applications from client 1 can access RLFS by mounting RLFS into its namespace, after which all file system calls to the mount point are forwarded to FUSE module 10 through VFS module 11 . The FUSE module 10 then relays the call instructions in the request queue to the daemon module 20 via the block device, where, by contacting the metadata server 200 and or other storage servers, the appropriate service handler is invoked to accommodate the file system call. The response propagates along the reverse path through the kernel section and eventually back to the application, which is usually in a wait state after making a request, waiting for a response. The daemon and storage server of RLFS should do all the semantics of PFS. For example, a read handler should first identify which storage servers have the requested data segment, and which in each server store the corresponding data segment, and then issue subrequests to those servers for parallel access. The kernel part also includes a file log module 12 for recording operation logs for the metadata server 200 .

In addition to the general semantics of PFS, RLFS also needs to implement region-based data layout capabilities. To achieve this goal, the RLFS is equipped with an I/O tracer 3, a cost calculation module 4, and an area division module 5 with three user-level components, through which the RLFS completes a three-phase data layout cycle. The data layout cycle begins with the trace phase, where I/O Tracer 3 collects runtime statistics of data accesses and filesystem summaries (e.g., FUSE queue information) for cost modeling during application execution into the trace file. The I/O tracer 3 then feeds the read/write traces to the zoning module 5, and in the next analysis phase the I/O tracer 3 directs the file system configuration file to the costing module 4, the zoning module 5 Utilize the updated cost model to generate regions, each assigning its own stripe size to both servers. Finally, in the placement stage, the file is placed on the underlying hybrid storage system 100 at runtime in order to optimize I/O requests in subsequent runs according to the layout scheme obtained in the previous stage. Through these three stages, RLFS can greatly improve the I/O performance of the application in subsequent runs. The RLFS also includes an update data layout module 8, which is respectively connected to the daemon process module 20, the I/O tracer 3, the area division module 5 and the hybrid storage system 100, and the update data layout module uses For dynamically updating the data layout, the updating data layout module is used to dynamically detect and update area changes. . Further, the specific functions of the I/O tracer 3, the cost calculation module 4 and the area division module 5 are described respectively:

1. I/O tracer 3

I/O Tracer 3 is used in RLFS to collect both runtime I/O information and file system configuration files. Although there are some technologies and tools that can be used for I/O data collection in the prior art, such as IOSIG [42], since the file system provided by the embodiment of the present invention is designed based on the FUSE framework, similar to the existing IOSIG [42] The I/O data collection tools in the technology are not directly applicable to RLFS. This is determined by the inherent characteristics of the FUSE framework structure. Therefore, in the I/O tracer 3 involved in this embodiment, which follows the N-1 journaling mode, all RLFS daemons are used to write to a single file share. Therefore, the designed I/O tracer 3 can help collect all information of I/O operations, including file access types, operation time and other process-related data.

After running the corresponding application using I/O tracer 3, the process ID, file descriptor, operation type, offset, request size and timestamp information can be obtained. To facilitate further partitioning and to guide optimal data layout, all I/O requests to a file are sorted in ascending order of their offsets.

The runtime I/O information is collected in a specific environment, and some parameters can also be used to fully understand the collected I/O information. To this end, in addition to the I/O information, the I/O tracer 3 should be allowed to further collect the runtime configuration files about the file system, especially the runtime configuration files of the file system based on the FUSE framework, which It will be directed to the cost calculation module 4 to assist the updated cost model, and the area division module 5 will further determine the optimal area division according to the minimum total cost obtained by the cost calculation module 4 .

2. Cost calculation module 4

The cost calculation module 4 can generate a cost model, and the cost model aims to find the minimum total cost.

In order to obtain the optimal area division and stripe size of each server in the storage system, the file system proposed in the embodiment of the present invention needs to rely on the cost calculation module 4 . In the cost calculation module 4, the cost is defined as the I/O completion time of each file request. The cost calculation module 4 is used to calculate the cost of file request access in the file system. The file system is compatible with hybrid storage systems.

Since the total access cost of the file request is related to the file system itself and the underlying network and storage server, the total access cost of the file request includes the system cost of the file system and the network and storage costs. Therefore, the calculation basis of the cost calculation module 4 should include the system cost of the file system and the network and storage cost. Correspondingly, the cost calculation module 4 includes a system cost calculation module 41 and a network and storage cost calculation module 42 .

Since the file system proposed by the embodiment of the present invention is built on the FUSE framework, the system cost of the file system mainly refers to the time overhead in the FUSE data path. Since the main goal of RLFS is to optimize read requests through the optimal location of data files on the hybrid storage system 100, only the system cost of read requests is defined in this embodiment, and the cost of write requests can also be determined by following export with the same parameters.

As shown in Figure 4, for each read request, its service time is divided into three sub-parts, one of which is the waiting time in the FUSE module 10, and the other is the time between the FUSE module 10 and the daemon module 20. The time of context switching, and the third is the time of three copy operations collected for the first copy.

Data flows from the network system containing m HServers and n SServers to the daemon process module 20 , and then from the daemon process module 20 to the FUSE module 10 , and finally sent to the client 1 by the FUSE module 10 .

The time waiting for a read request in the FUSE module 10 queue is closely related to the application running between Client 1 and RLFS, the time waiting for a read request in the FUSE module 10 queue depends not only on the I/O requests made by the application mode, which is also related to other factors caused by the file system, such as page caching or interrupts. Therefore, it is difficult to estimate it accurately. However, when considering the factor of minimizing queue delays through the multithreading support of the daemon module 20 of RLFS, it is safe to assume that the waiting time for read requests in the FUSE module 10 queue is negligible, ie _Tq= 0.

Further, the context switch time is system-dependent and independent of the data size, and can be treated as a constant value. Therefore, the calculation formula of the time T _s for two context switches between the FUSE module 10 and the daemon process module 20 is: T _s =2μ. where μ is the context switch time.

The time of the three copy operations collected for the first copy is referred to as the copy time T _c , and the copy time T _c is proportional to the data size r of the file request. The calculation formula is:

T _c (r,h,s)=3rt _c

The data size of the file request is r, and the calculation formula of the data size r of the file request is:

r=ms _m +ns _n

s _m and s _n represent the maximum sub-request size on HServer and the maximum sub-request size on SServer respectively, and s _m ≤ h and s _n ≤ s, h represents the stripe size on HServer, s represents the stripe size on SServer, So, further, the copy time T _c can be expressed as:

T _c (r,h,s)≈3(mh+ns)t _c

t _c is the unit data copy time from kernel space to user space. Therefore, the first part of the total cost calculated by the system cost calculation module 41 is denoted as T ₁ , where T ₁ =T _s +T _c .

The network and storage costs calculated by the network and storage cost calculation module 42 include: network connection time _Te , storage access time _Ta and network transmission time _Tx . In PFS, requests are divided into a set of subtasks, each of which is forwarded to a separate storage server for parallel execution. Therefore, the request subcomponent cost in the network and storage servers is determined by the maximum cost of all subrequests. Assuming that each type of server (HServer or SServer) has the same configuration for the network and storage, the network transmission time Tx can be determined according to the data size (s _m and s _n ) and the data transmission network time _t . The specific formula is:

In the above formula, s _m and s _n represent the maximum sub-request size on HServer and the maximum sub-request size on SServer, respectively.

Similar to the network transmission time T _x , the storage access time T _a is determined by the sub-request, and the specific formula is:

In the above formula, s _m and s _n represent the maximum sub-request size on HServer and the maximum sub-request size on SServer, respectively, and _th and _ts represent the unit data transmission time on HServer and the unit data transmission time on SServer, respectively.

Unlike the storage access time T _a and the network transmission time T _x , the network connection time T _e is a constant, which is independent of the data size. To sum up, the network and storage cost interval T2 calculated by the network and storage cost calculation module 42 can be expressed by the _formula :

Further network and storage cost time T2 can be expressed as _:

T ₂ ≈T _e +max{h(t _h +t),s(t _s +t)}

In the above formula, h represents the size of the stripe on the HServer, and s represents the size of the stripe on the SServer.

It can be seen from the cost calculation module 4 that the total cost T of the request can be expressed as: T=T ₁ +T ₂ , and the total cost of the request is a function of parameters describing the application, file system and data layout. Therefore, it is highly heterogeneous, determined by the server stripe sizes h and s.

In addition, it should be noted that since the read and write in SServers are very different, the write request involves more operations than the read. At this time, two contexts are performed between the FUSE module 10 and the daemon module 20. The switching time T _s needs to add the time of write amplification, garbage collection and wear leveling.

In order to facilitate the explanation of the working principle of the cost calculation module 4, the parameters of the cost analysis mode involved in the cost calculation module 4 are presented in a table form, as shown in Table 1.

Table 1 Parameters in Cost Analysis Mode

3. Regional division module 5

Guided by the cost model generated by the cost calculation module 4, the region partition module 5 is able to partition files into different regions in an attempt to minimize the total cost of a given set of accesses characterized by parallel applications. The existing area division device includes HARL, and HARL divides area division and strip size determination into two different stages. Different from HARL, the layout strategy of RLFS is integral, and the layout strategy of RLFS is based on a unified The method considers the problem of area division and strip size determination, so RLFS can determine the area division and strip size at one time. Instead of heuristically scanning trace files for logical regions like HARL, RLFS puts logical regions and physical blocks together with the goal of having the smallest overall cost. This consideration is easy to understand because the smallest unit of file access is a block, such as 64MB or 128MB, and logical regions can naturally span a sequence of adjacent physical blocks.

A first algorithm can be executed in the area division module 5, the first algorithm is the most relatively fast algorithm in an offline form, and the first algorithm can be repeated periodically to adapt to the dynamic nature of the visit. "relatively fast" means that the algorithm is pseudo-polynomial time, and the essence of the algorithm is to first represent the shared file as a sequence of blocks, then partition the file in blocks according to a given access request, and finally use the dynamic programming module to extract data from these partitions. to find the optimal region division.

An example of a file F having size L, defined by the number of segments (L=12 segments), and a sequence of adjacent segments are merged into regions, according to an I/O event given by the access mode, such as starting or ending an I/O operation, Each area is isolated by a red vertical dashed line. The data for each region is striped between the HServer and the SServer, and logical I/O requests can be handled by a single for multiple physical requests related to the requested data. With this layout optimization, the cost of total access is minimized according to the defined cost model compared to traditional strategies.

表示从索引i开始的具有l请求事件的文件被划分为k区域时的最小成本，由以下递归来计算0≤i<l的：Assume

represents the minimum cost when a file with l request events starting at index i is divided into k regions, computed by the following recursion for 0 ≤ i < l:

定义了一个区域，其大小为

可以表示为：in,

defines a region whose size is

It can be expressed as:

将在HServer和SServer中被条带化，分别为h_i和s_i。

will be striped in HServer and _SServer , hi and _si respectively.

当m从l变化到l-i时，将尺寸为f的第一区域的成本

相加到剩余的

中，从而计算出最小和。当段的数目不足以支持剩下的k区域划分，设置

否则设置

The minimum cost of dividing l events into k regions starting from event i can be obtained from recursion

Convert the cost of the first region of size f as m varies from l to li

add to the remaining

, so as to calculate the minimum sum. When the number of segments is not enough to support the remaining k region divisions, set

otherwise set

的定义后，进一步计算从

到

区域的(子)请求，然后计算

的成本

计算公式如下：give

After the definition of , further calculations are made from

arrive

(sub)requests for the region, then compute

the cost of

Calculated as follows:

In the above formula, T(r, h _i , s _i ) is defined in the cost model, assuming that s _i = αhi _i , then there are:

Here, α≥1 is the expansion factor of SServer relative to HServer, and B represents the block size in the configuration.

Through the above 4 equations, one can get the optimal partition of the file layout and minimize the cost for a given request. Further, the file is partitioned and placed on the underlying heterogeneous server, and each area on the underlying heterogeneous server has a certain stripe size corresponding to it. Thereafter, for each request R, the corresponding region can be read according to its stripe size to satisfy the requirement.

FIG. 5 is a diagram of an example application of a file system in an embodiment of the present invention. As shown in FIG. 5, the file client 1 issues requests on behalf of the application from the computing server 301, the hybrid storage system 100 is responsible for storing and managing the stripped area, and the metadata server 200 (MDS) contains the files stored in the RLFS. Description. During file operations, client 1 first contacts the MDS to obtain file metadata, and then utilizes it for data access with the hybrid storage system 100 through the RLFS daemon.

RLFS logically maps a large file into multiple small (regional) files, each representing a region of the file with a similar I/O workload. Zone files are further stripped across all HServers and SServers, and each stripe is stored as a separate data file in each storage server. To this end, MDS maintains a region strip table (RST) for each physical file in RLFS, as shown in Table 2 below, in which each region of the file is recorded according to the offset and stripe size in each server. The region strip table (RST) is created by the region partition module 5 when a file is written to the RLFS, and the region strip table (RST) is updated when the access mode changes. For efficiency, RST caches and caches of files to be read when RLFS is installed and uninstalled can be stored in the same directory as the application.

Table 2 area bar table data structure

For cost calculation module 4, a file server in the parallel file system is used to test the context switching time, unit data replication time and unit data transfer time of HServer and SServer with read/write mode. These parameters can vary with different I/W O mode changes. In addition, using a pair of nodes, a client node and a file server, to estimate the network transfer time, the network transfer time test can be repeated thousands of times, and then their averages are calculated as parameter values for the generative cost model.

To perform the optimal data layout for a particular file, RLFS first uses its region partitioning module 5 to calculate the optimal partitioning of the file, and then utilizes the cost model and I/O trace data to determine the stripe size for each region. The optimal region information is calculated for simultaneously writing files on each server, and the region division module 5 creates an RST for the files in the MDS for subsequent reading. MDS holds RLFS's namespace, RST, and other information about each file. However, due to the limited number of regions given by the region division algorithm, the size of the MDS is highly controlled and the size of the MDS is small.

In addition, to facilitate parallel reading of each file, the hybrid storage system 100 maintains a flat namespace, where each file can be identified by "filename_region#_stripe#" in the local disk. Note that "filename" can contain application-specific path information. The background I/O daemon is used to receive incoming requests from Client 1, characterized by "filename", "region#" and "stripe#", and service the request by sending back the requested stripe file, which stripes Strip files are combined with other strip files to meet the needs of the application.

A file system (RLFS) proposed by the present invention supports region-level data layout by dividing the file into a set of optimal regions, so that the optimal region and its stripe size can be determined by the file system. Therefore, by The file system can optimize the data layout of the hybrid storage system 100 . Using the FUSE module 10 not only greatly simplifies the development effort compared to the kernel approach, but also allows access to RLFS through a standard file system interface, enabling applications to access RLFS in a transparent manner. It can flexibly adapt to workload changes and server heterogeneity, thereby significantly accelerating I/O system performance.

The file system (RLFS) proposed by the embodiment of the present invention has been verified by experiments, and it is confirmed that it is feasible and has excellent performance. The experimental results show that RLFS can work well with the hybrid storage system 100, and RLFS can greatly improve the parallel I/O performance.

In the experiment, three data layout schemes are compared: scheme one uses strips of fixed size; scheme two uses randomly selected stripes, and scheme three is implemented by RLFS. For read and write, RLFS uses the optimal data layout of {32KB, 160KB} and {36KB, 148KB}, respectively, which improves I/O performance by 73.4% and 176.7% compared to the default layout with fixed-size stripes of 64KB %. Compared to other layouts with different but fixed-sized stripes, RLFS improves read performance to 138.6% and write performance to 177.6%. Compared to the randomly chosen striping strategy, RLFS improves read performance to 154.5% and write performance to 215.4%.

Experimental results based on representative benchmarks show that RLFS is a promising and feasible solution in hybrid parallel file systems, with parallel I/O performance improving from 20.6% to 556.1% for reads and 22.7% to 288.7% for writes .

The present invention also provides a data layout method, which includes:

In step S1, the I/O information of the data access at runtime and the file system configuration file used for cost modeling are collected into the tracking file, the file system configuration file is directed to establish the cost model, and the I/O information is used for the cost modeling. regional division;

Step S2, calculate or estimate the access cost of the file request to form a cost model;

Step S3, according to the cost model to generate a distribution area where the total cost is minimized, and divide the file into different areas;

Step S4, acquiring the strip size corresponding to the area.

The beneficial effect of the above method is that the method supports the data layout at the area level by dividing the file into a set of optimal areas, so as to determine the optimal area and its stripe size, and the method optimizes the data of the hybrid storage system. layout.

The above-mentioned embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: it can still be used for the foregoing implementations. The technical solutions described in the examples are modified, or some technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the within the protection scope of the present invention.

Claims (8)

1. A file system is characterized in that the file system comprises an I/O tracer, a cost calculation module and a region division module which are electrically connected with each other, wherein the I/O tracer is used for providing I/O information collected by the I/O tracer when the file system runs to the region division module; the I/O tracer is also used for providing the cost calculation module with the configuration file of the file system collected by the I/O tracer; the cost calculation module is used for calculating or predicting the access cost of the file request in the file system so as to output a cost model to the region division module; the area dividing module is used for generating a distribution area with the minimized total cost according to the cost model and dividing files into different areas, and the area dividing module is also used for obtaining the size of a strip corresponding to the area;

the cost calculation module is used for calculating the total cost of the request, and the total cost calculation formula is as follows: t ═ T_s+T_c+T₂In the formula, T_sRepresents the time of two context switches between the FUSE module and the daemon module, T_cDenotes the reproduction time, T₂Representing network and storage costs.

2. The file system of claim 1, wherein the file system further comprises a kernel portion for performing interaction of information or data between a metadata server, the hybrid storage system, and a client party; the kernel portion includes a FUSE module.

3. The file system of claim 2, wherein the file system further comprises a daemon module for executing a daemon process in the background; the FUSE module is used as a proxy of the daemon.

4. The file system of claim 3, wherein the file system further comprises an update data placement module, the update data placement module being respectively coupled to the daemon module, the I/O tracer, the zoning module, and the hybrid storage system, the update data placement module being configured to dynamically detect and update a change in a zone.

5. The file system of claim 4, wherein the hybrid storage system comprises a solid state drive-based server SServer and a hard disk drive-based server HServer;

the calculation formula of the replication time is as follows: t is_c(r，h，s)≈3(mh+ns)t_cIn the formula t_cRepresenting the unit data copying time from a kernel space to a user space, r representing the data size of a file request, h representing the size of a stripe on an HServer, s representing the size of a stripe on an SServer, m representing the number of the HServers, and n representing the number of the SServers;

the calculation formula of the network and storage cost is as follows: t is₂≈T_e+max{h(t_h+t)，s(t_s+ t) }, where t denotes the data transmission network time, t_hAnd t_sRespectively representing the cell data transmission time on HServer and the cell data transmission time on SServer, T_eRepresenting the network connection time.

6. The file system of claim 5, wherein the region partitioning module is to obtain the secondary data fromMinimum cost to start dividing l events into k regions for event i

The minimum cost

The calculation formula of (2) is as follows:

in the formula, the first step is that,

define a size of

The area of the image to be displayed is,

the cost of the first area of size f is indicated.

7. The file system of claim 6, wherein the solid state drive based server and the hard drive based server are capable of connecting

Striping and obtaining h respectively_iAnd s_i，s_iIs calculated as s_i＝αh_i，h_iThe calculation formula of (2) is as follows:

in the formula, α ≧ 1 and is the SServer spreading factor relative to HServer, B denotes the block size in the configuration.

8. A data layout method using the file system according to any one of claims 1 to 7, characterized by comprising:

step S1, collecting the I/O information of data access during operation and the file system configuration file for cost modeling into a tracking file, orienting the file system configuration file for establishing a cost model, and using the I/O information for region division;

step S2, calculating or estimating the access cost of the file request to form a cost model;

step S3, generating a distribution area with minimized total cost according to the cost model, and dividing the files into different areas;

step S4, obtaining the size of the strip corresponding to the area.

Images