KR20150087622A - Distributed file system for providing the file-based snapshot and method thereof - Google Patents

Abstract

The present invention relates to a distributed file system and operating method thereof. The distributed file system includes: a metadata server which manages the metadata information of files and the metadata information of snap shot files at the file level; and multiple data servers which divide the file data in chunk units to store and manage the file data, stores and manages the delta chunks of the snapshot files for the chunks of original files, and manages the input and output of the snapshot files or the original files.

Description

[0001] The present invention relates to a distributed file system providing file-level snapshots,

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a distributed file system, and more particularly, to a distributed file system that provides file-level snapshots.

In the Internet business application environment, the stability and the availability of the system are required as well as the processing of large amounts of data and expansion of the storage space. However, it takes a long time to back up a large amount of data and it is unacceptable to stop service during this time. Therefore, an online backup (on-line) is required to provide a backup while the service is being provided, and a snapshot technique is needed to support such online backup. In other words, snapshots are a technique for maintaining a point-in-time file system or volume image, allowing you to perform online backups via snapshots while providing services

On the other hand, a general file system provides snapshots at the file system or volume level, and has a structure for managing file metadata and data together. Here, a snapshot is used to support a backup in an online state by keeping the current state at the file system or volume level at a certain point in time. In addition, recent support for snapshots of virtual desktop images or virtual disks in a virtual desktop environment enables them to return to snapshot status at a specific point in time, or snapshots of virtual desktop images to quickly create virtual desktop images Is used for distribution.

However, recent large-capacity file systems mostly have a distributed file system structure in which metadata and data of files are separated and managed by metadata server and data server. As a result, there is a need for a way to support snapshots at the file level.

To provide file-level snapshots in a distributed file system with an asymmetric structure, the metadata server manages the metadata of the original files and the snapshot files. In the data servers, data about the original file and the snapshot file Is required. In addition, consistency must be ensured for source files and snapshot files.

The present invention aims to provide a technical solution for supporting read-only or writable snapshots at a file level in a distributed file system.

According to an aspect of the present invention, there is provided a distributed file system including a metadata server for managing metadata information of a file, managing metadata information for a snapshot file at a file level, A plurality of data servers for storing and managing the chunks of the original file, and for storing and managing the delta chunks of the snapshot files, and managing input / output of the original files or the snapshot files do.

According to the present invention, the meta data server shares metadata with respect to the original file and the snapshot file to assure consistency, thereby supporting faster snapshot creation and management. In the data server, data about the original file or the snapshot file By processing I / O and update requests efficiently according to the characteristics of the snapshot, transparent processing can be supported for the metadata server or client.

1 is a block diagram showing a configuration of a distributed file system according to an embodiment of the present invention;
FIG. 2 conceptually illustrates a file-level read-only snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
FIG. 3 is a view schematically showing a metadata structure of a file-level read-only snapshot file managed by a metadata server of a distributed file system according to an embodiment of the present invention; FIG.
FIG. 4 is a diagram schematically illustrating identifier configuration information for identifying a delta chunk of a read-only snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
5 is a view schematically showing a original chunk extent change map for tracking update data information on an extent basis in a distributed file system according to an embodiment of the present invention;
FIG. 6 is a flowchart illustrating a process of generating a file-level read-only snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
7 is a flowchart illustrating a process of deleting a file-level read-only snapshot file in a distributed file system according to an embodiment of the present invention;
FIG. 8 is a flowchart illustrating a write process of an original file in a distributed file system according to an embodiment of the present invention; FIG.
FIG. 9 is a flowchart illustrating a reading process of an original file in a distributed file system according to an embodiment of the present invention; FIG.
FIG. 10 is a flowchart illustrating a read process of a file-level read-only snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
FIG. 11 conceptually illustrates a file-level writeable snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
12 is a view schematically showing a metadata structure of a file-level writeable snapshot file managed by a metadata server of a distributed file system according to an embodiment of the present invention;
13 is a view schematically showing identifier configuration information for identifying a delta chunk of a writable snapshot file in a distributed file system according to an embodiment of the present invention;
FIG. 14 is a flowchart illustrating a process of generating a file-level writeable snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
15 is a flowchart illustrating a process of converting a file-level read-only snapshot file into a writable snapshot file in a distributed file system according to an embodiment of the present invention;
FIG. 16 is a flowchart illustrating a write process for a file-level writeable snapshot file in a distributed file system according to an embodiment of the present invention; FIG.
FIG. 17 is a flowchart illustrating a read process of a file-level writeable snapshot file in a distributed file system according to an embodiment of the present invention; FIG.

BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and further aspects of the present invention will become more apparent from the following detailed description of preferred embodiments with reference to the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Before describing the present invention in detail, the present invention manages meta data of a file in an independent metadata server, divides the data of the file into chunks of fixed size, distributes and manages the data to a plurality of data servers, Distributed file system with asymmetric data access path and file data access path.

1 is a block diagram showing a configuration of a distributed file system according to an embodiment of the present invention.

The client 110 may perform a client application, access metadata of a file stored in the metadata server 120, and input / output data of a file stored in the data server S140. That is, in order for the client 110 to access the file, first the file metadata in the metadata server 120 is accessed to obtain information about the plurality of data servers 130 in which the file data is stored, Output is performed through a plurality of data servers 130.

The metadata server 120 stores and manages metadata of all files in the file system, and manages status information on all the data servers S140. Specifically, the metadata server 120 manages the metadata information of the file, and manages the metadata information of the snapshot file at the file level.

Here, snapshots can be managed as read-only snapshots or writable snapshots, depending on their characteristics, and both snapshots share metadata about the original file data. Read-only snapshots can only read file data at the point of creation of the snapshot, and the original file is continuously changed. Write-enabled snapshots can be read-write to the snapshot after the snapshot is created. Thus, although the original file and snapshot share metadata about the file data, changes to the original file are not reflected in the snapshot, and changes to the snapshot are not reflected in the original file.

The data server (S140) stores and manages data chunks of the file, and periodically reports its status information to the metadata server (120). Specifically, the data server 130 stores and manages the data of the file in units of chunks, and stores and manages the delta chunks of the snapshot files with respect to the chunks of the original files. The input / . Preferably, the data server 130 manages the input and output of chunks of data in the file, reflecting the characteristics of these read-only snapshots or writable snapshots.

The data server S140 of the distributed file system 10 is preferably composed of a plurality of data servers and the client 110, the metadata server 120 and the plurality of data servers S140 are interconnected via a network.

Hereinafter, a distributed file system and its method for providing a file-level read-only snapshot will be described with reference to FIGS. 2 to 10. FIG.

FIG. 2 conceptually illustrates a file-level read-only snapshot file in a distributed file system according to an embodiment of the present invention.

A file-level read-only snapshot file holds the state at the time the snapshot is taken of the original file. Therefore, even if the original file continues to be updated after the snapshot is created, it can be restored to the state of the file at the time the specific snapshot was created. Read-only snapshots can be created continuously over time, and each snapshot retains the state of the original file at the time the snapshot is created. To this end, the read-only snapshots 203, 205, and 207 are created in the same file format as the original file. The chunks storing the data are stored in the snapshot delta chunks 104, 106, and 108, which store only the data updated after the snapshot without updating the original chunks 202 when data updates occur after the snapshot is generated , Allowing access to the data at the time of the snapshot when returning to a specific snapshot.

FIG. 3 is a diagram schematically illustrating a metadata structure of a file-level read-only snapshot file managed by a metadata server of a distributed file system according to an embodiment of the present invention.

Metadata information about the original file and the read-only snapshot file is managed by the inode structure 301, 306, 311, 316 in the metadata server 120. The inode structure includes inode attribute information (302, 307, 312, 317) and chunk layout information that is divided and stored in the data server 130. Here, the inode attribute information includes an inode identifier, a file type, a file mode, a file size, a file ownership, a file access / change / update time, and the like. The chunk layout information includes chunk layout header information 304, 309, 314, 319 having information on the number of chunks, chunk size, and number of chunk replicas, chunk information 305, 310, 315, 320 having chunk identifier, chunk identifier, chunk type, . In addition, in the original file, the inode information of the read-only snapshot file generated from the original file is maintained (303), whereas the inode of the read-only snapshot file retains the inode information of the original file (308, 313, 318) The relationship with the shot file is set.

4 is a diagram schematically showing identifier configuration information for identifying a delta chunk of a read-only snapshot file in a distributed file system according to an embodiment of the present invention.

Specifically, FIG. 4 identifies a delta chunk of a read-only snapshot file that stores update data when a chunk of the original file is updated after a file-level read-only snapshot file is created in the distributed file system 10 Is the identifier configuration information to be used. Here, the delta chunk of the read-only snapshot file is identified by using the identifier 401 of the original chunk and the read-only snapshot number 402 without allocating a separate chunk identifier as in the chunk of the original file. Therefore, in the chunk information of the read-only snapshot file, the disk identifier and the chunk identifier where the chunk is stored remain the same as the chunk of the original file.

FIG. 5 is a diagram schematically showing a original chunk extent change map for tracking update data information on an extent basis in a distributed file system according to an embodiment of the present invention.

Specifically, FIG. 5 shows an original chunk extent change map for tracking update data information in units of extents when a chunk of an original file is updated after a file-level read-only snapshot file is created in the distributed file system 10 to be. The distributed file system 10 stores data that is updated in the snapshot delta chunk when a chunk of the original file is updated after a read-only snapshot file is created. Here, the update uses the copy-on-write method in units of extent.

That is, when the chunk is divided into extent units, the distributed file system 10 updates the data by reading the extent from the original chunk or the delta chunk of the previous read-only snapshot, updating the current read-only snapshot Store in delta chunk. At this time, in order to track which extents are changed after a certain read-only snapshot number with respect to the extents constituting the chunk, the distributed file system 10 stores the extent number and the read-only snapshot number 502, Keeps the extent change map at the end of the original chunk. The distributed file system 10 also keeps the originally created read-only snapshot number 501 in the original chunk extent change map.

6 is a flowchart illustrating a process of generating a file-level read-only snapshot file in the distributed file system according to the embodiment of the present invention.

First, the distributed file system 10 acquires the lock of the original file inode (S601). This ensures the consistency of snapshot creation by acquiring a lock on the original file inode to create a read-only snapshot of the original file. After acquiring the lock, the distributed file system 10 creates a snapshot file inode, assigns a read-only snapshot number, and sets the mode of the snapshot file to read-only (S602). Next, the distributed file system 10 copies the chunk layout information of the original file or the previously created read-only snapshot to the chunk layout information of the newly created read-only snapshot (S603).

In addition, the distributed file system 10 acquires a lock of the original chunk or the previously created snapshot delta chunk in all the data servers 130 storing the chunk of the original file (S604) Delta chunks for the snapshot are generated (S605).

At this time, if there is data update for the original chunk or the previous snapshot delta chunk, the distributed file system 10 stores the newly created snapshot delta chunk and reflects it in the extent change map of the original chunk (S606). Thereafter, the original chunk or the previously created snapshot delta chunk is unlocked (S607).

In addition, the distributed file system 10 stores the inode information of the original file in the inode of the snapshot file newly created by the metadata server 120 (S608), and the newly created read-only snapshot file And stores the inode identifier and the snapshot number (S609). Finally, the distributed file system 10 unlocks the original file inode (S610) and ends the process of creating a file-level read-only snapshot file.

7 is a flowchart illustrating a process of deleting a file-level read-only snapshot file in the distributed file system according to the embodiment of the present invention.

In order to delete the read-only snapshot file, the distributed file system 10 performs a different process according to whether the snapshot file to be deleted is the first snapshot created for the original file (S701).

If the first snapshot to be deleted is the first created read-only snapshot file, the distributed file system 10 analyzes the extent change map of the original chunk in the data server 130 storing the chunk in step S702, , The snapshot delta chunk storing the changed data after the snapshot to be deleted is created is merged with the original chunk (S703). After merging, the distributed file system 10 deletes the read-only snapshot delta chunk to be deleted from the data server 130 (S704).

If the snapshot to be deleted is not the firstly created read-only snapshot, the distributed file system 10 analyzes the extent change map of the original chunk in the data server 130 storing the chunk (S705) The snapshot delta chunk storing the changed data after the snapshot to be deleted is created, and the snapshot delta chunk storing the changed data after the snapshot created before the deletion target snapshot are merged (S706). After merging, the data server 130 of the distributed file system 10 deletes the read-only snapshot delta chunk to be deleted (S707).

After this process, the data server 130 of the distributed file system 10 initializes the snapshot number to be deleted of the extent change map of the original chunk, or changes and stores the snapshot number to the previous snapshot number (S708). Then, the distributed file system 10 deletes the read-only snapshot inode information to be deleted from the inode of the original file (S709). Finally, the distributed file system 10 deletes the inode of the snapshot file (S710) and ends the process of deleting the file-level read-only snapshot file.

8 is a flowchart illustrating a write process of an original file in a distributed file system according to an embodiment of the present invention. Specifically, the distributed file system 10 can write data to the original file from the client 110 after creating the file-level read-only snapshot file.

To this end, the distributed file system 10 requests and receives chunk layout information of an original file from the metadata server 120 in the client 110 (S801). Then, the client 110 requests the data server 130 storing the chunk of the data write location to write data (S802). Then, the data server 130 of the distributed file system 10 first analyzes the extent change map of the original chunk (S803) and checks whether the extent of the data write location in the chunk is changed (S804).

If the extent has changed, the distributed file system 10 obtains a lock on the read-only snapshot delta chunk having the last change data and the current (last) read-only snapshot delta chunk (S805). The distributed file system 10 performs an extent-by-extent copy-on-write from the last changed snapshot delta chunk to the current snapshot delta chunk (S806), and then locks the last changed snapshot delta chunk and the current snapshot delta chunk (S807).

If the extent has not been changed, it means that the original chunk has not changed at all, so the distributed file system 10 obtains the lock of the original chunk and the current snapshot delta chunk (S808). The distributed file system 10 performs copy-on-write from the original chunk to the current snapshot delta chunk (S809), and then unlocks the original chunk and the current snapshot delta chunk (S810).

Thereafter, the distributed file system 10 is able to track the last changed location by setting the last (current) read-only snapshot number for the extent in the extent change map of the original chunk (S811).

9 is a flowchart illustrating a reading process of an original file in a distributed file system according to an embodiment of the present invention. Specifically, the distributed file system 10 can create a file-level read-only snapshot file and then perform a read process on the original file.

When reading the original file after creating the read-only snapshot file, the distributed file system 10 first requests the client 110 to receive the chunk layout information of the original file from the metadata server 120 (S901). In addition, the client 110 of the distributed file system 10 requests the data server 130, which stores data to be read in the chunk layout, to read data (S902). Then, the data server of the distributed file system 10 analyzes the extent change map of the original chunk (S903), and checks whether the extent has been changed since the snapshot was created (S904).

If the extent has been changed as a result of the check in step S904, the distributed file system 10 acquires the lock of the snapshot delta chunk storing the last changed data (S905) and reads the data from the last change read-only snapshot delta chunk To the client 110 (S906), and then unlocks the last changed snapshot delta chunk (S907).

If the extent has not been changed as a result of the check in step S904, the original chunk has not been changed after the snapshot has been created. Therefore, the distributed file system 10 acquires the lock of the original chunk (S908) And transmits it to the client 110 (S909), and then unlocks the original chunk (S910).

10 is a flowchart illustrating a read processing procedure for a file-level read-only snapshot file in the distributed file system according to the embodiment of the present invention.

Specifically, when reading a read-only snapshot file, the distributed file system 10 first requests the client 110 to request chunk layout information of the snapshot file from the metadata server 120 (S1001). The client 110 of the distributed file system 10 transmits a data read request to the data server storing the data to be read (S1002). Then, the data server 130 of the distributed file system 10 analyzes the extent change map of the original chunk (S1003), and checks whether the extent has been changed before the snapshot (S1004).

If the extent of the check is changed in step S1004, the distributed file system 10 acquires the lock of the snapshot delta chunk storing the previously changed extent (S1005), reads the data from the previously changed extent, (S1006), and then unlocks the previously changed read-only snapshot delta chunk (S1007).

If the extent has not been changed as a result of the check in step S1004, the distributed file system 10 acquires the lock of the original chunk (S1008), reads the data from the original chunk and transmits it to the client 110 (S1009) The chunk is unlocked (S1010).

Hereinafter, a distributed file system and its method for providing a file-level writeable snapshot will be described with reference to FIGS. 11 to 17. FIG.

11 is a view conceptually showing a file-level writeable snapshot file in a distributed file system according to an embodiment of the present invention.

File-level writable snapshots, like read-only snapshots, share metadata and metadata information at the time of snapshot creation, but read and write to snapshots independent of the original file, unlike read-only snapshots Do. Changes to the original file are not reflected in the writable snapshot, and changes to the writable snapshot are not reflected in the original file.

Thus, the change to the original chunks 1102 of the original file 1101 is maintained as a read-only snapshot delta chunk, and the writable snapshots 1003, 1005, 1007 are separately maintained as writable snapshot delta chunks 1004 , 1006,1008), and the data in the writable snapshot changes, copy-on-write is performed using the original chunk and the read-only snapshot delta chunk.

12 is a view schematically showing a metadata structure of a file-level writeable snapshot file managed by a metadata server of a distributed file system according to an embodiment of the present invention.

Specifically, metadata of the original file 1201 and the writable snapshot files 1206, 1211, and 1216 are managed by the metadata server 120 in an inode structure. At this time, the inode attribute information 1202, 1207, 1212 and 1217 and the chunk layout information 1204, 1205, 1209, 1210, 1214, 1215, 1219 and 1220 are managed in the inode. This information is the same as a read-only snapshot file. Also, the inode information 1203 for the writable snapshot is maintained in the original file inode, and the inode information 1108, 1113, and 1118 of the original file is retained in the writable snapshots.

13 is a diagram schematically showing identifier configuration information for identifying a delta chunk of a writable snapshot file in a distributed file system according to an embodiment of the present invention.

Specifically, FIG. 13 identifies a delta chunk of a writable snapshot file that stores update data when a chunk of the original file is updated after generating a file-level writeable snapshot file in the distributed file system 10 Is the identifier configuration information to be used. Here, the delta chunk of the writable snapshot file is composed of the identifier (S1401) of the original chunk and the writable snapshot number (S1402). Thus, the distributed file system 10 does not allocate a separate chunk identifier for the writable snapshot delta chunk.

FIG. 14 is a flowchart illustrating a process of generating a file-level writeable snapshot file in the distributed file system according to an embodiment of the present invention.

Specifically, in order to create a writable snapshot of the original file, the distributed file system 10 first acquires a lock of the original file inode (S1401). Then, the distributed file system 10 creates a writable snapshot inode and allocates a writable snapshot number (S1402). In addition, the distributed file system 10 copies the chunk layout information of the original file inode to the chunk layout information of the writable snapshot inode (S1403).

The distributed file system 10 acquires a lock of the original chunk in all the data servers 130 storing the chunk with reference to the chunk layout (S1404), and generates a writable snapshot delta chunk (S1405). If there is a data write to the original chunk, the distributed file system 10 copies-in-write the corresponding extent of the original chunk to the generated snapshot delta chunk and reflects the extent change bitmap of the snapshot delta chunk (S1406), and the data server 130 releases the lock of the original chunk (S1407).

Thereafter, the distributed file system 10 stores the original file inode information in the writeable snapshot file inode (S1408), and adds the newly created writeable snapshot file inode information and the snapshot number to the original file inode (S1409 ). Finally, the distributed file system 10 unlocks the original file inode (S1410) and ends the process of creating a file-level writeable snapshot file.

15 is a flowchart illustrating a process of converting a file-level read-only snapshot file into a writable snapshot file in the distributed file system according to an embodiment of the present invention. Specifically, the writable snapshot file of the distributed file system 10 may be converted from a read-only snapshot file.

To this end, the distributed file system 10 first acquires the lock of the original file and the read-only snapshot file inode (S1501). Then, the distributed file system 10 changes the type of the read-only snapshot file to a writable snapshot file and gives a writeable snapshot number (S1502). In addition, the distributed file system 10 obtains a lock on the previous snapshot delta chunks in the data server 130 (S1503) for all chunks by referring to the chunk layout information of the read-only snapshot file And generates a snapshot delta chunk (S1504).

The data server 130 of the distributed file system 10 merges the previous read-only snapshot delta chunks into writable snapshot delta chunks (S1505). Then, the delta chunks of the read-only snapshot changing from the data server 130 of the distributed file system 10 to the writable snapshot are merged into the previous snapshot delta chunk (S1506).

In step S1506, the distributed file system 10 changes the read-only snapshot number to the previous read-only snapshot number in the original chunk extent change map (step S1507) The original chunk is unlocked in step S1508. The metadata server 120 of the distributed file system 10 deletes the read-only snapshot file inode information from the original file inode and adds the writeable snapshot file inode identifier and number to the writable snapshot inode information (S1509 ). Finally, the distributed file system 10 unlocks the original file inode (S1510) and ends the process of converting the file-level read-only snapshot file into a writable snapshot file.

16 is a flowchart illustrating a write process for a file-level writeable snapshot file in the distributed file system according to an embodiment of the present invention.

In order to process the write-enabled snapshot file, the distributed file system 10 first requests the client 110 to request the chunk layout information of the writable snapshot file from the metadata server 120 (S1601). The client 110 of the distributed file system 10 requests the data server 130 storing the chunk for the data to be written to write data (S1602). In step S1603, the data server 130 of the distributed file system 10 analyzes the extent change bitmap of the writable snapshot delta chunk in step S1603. In step S1604, it is determined whether the extent of the location is changed in the write data.

If the extent has been changed as a result of the check in step S1604, the distributed file system 10 acquires the lock of the snapshot delta chunk (S1605), writes the data to the writable snapshot delta chunk (S1606) The chunk is unlocked (S1607).

If it is determined in step S1604 that the corresponding extent has not been changed, the distributed file system 10 acquires a lock of the original chunk and the snapshot delta chunk (S1608), and copies the copy chunk from the original chunk to the snapshot delta chunk -write is executed (S1609). Then, the distributed file system 10 sets the extent change bitmap of the writable snapshot delta chunk to that the extent is changed (S1610). Finally, the distributed file system 10 unlocks the original chunk and writable snapshot delta chunk (S1611) and ends the write process for the file-level writeable snapshot file.

17 is a flowchart illustrating a reading process of a file-level writeable snapshot file in a distributed file system according to an embodiment of the present invention.

In order to read data from the writable snapshot file, the distributed file system 10 first requests the client 110 to request the chunk layout information of the writable snapshot from the metadata server 120 (S1701). Then, the client 110 of the distributed file system 10 requests the data server 130, which stores the chunk of the data to be read, to read the data (S1702). Accordingly, the data server 130 of the distributed file system 10 analyzes the extent change bitmap of the writable snapshot delta chunk (S1703) and checks whether the extent corresponding to the data to be read is changed (S1704).

If it is determined in step S1704 that the corresponding extent has been changed, the distributed file system 10 acquires the lock of the writable snapshot delta chunk (S1705), reads the data from the writable snapshot delta chunk and transmits it to the client (S1706) , The snapshot delta chunk is unlocked (S1707).

If it is determined in step S1704 that the corresponding extent has not been changed, the distributed file system 10 acquires the lock of the original chunk (S1708), reads the data from the original chunk, and transmits the data to the client 110 (S1709) Unlocking the original chunk (S1710) terminates the read process for the file-level write-enabled snapshot file.

As described above, according to the present invention, the meta data server shares the metadata of the original file and the snapshot file to assure consistency, thereby supporting faster snapshot creation and management. In the data server, data of the original file or the snapshot file By processing I / O and update requests efficiently according to the characteristics of the snapshot, transparent processing can be supported for the metadata server or client.

The present invention has been described with reference to the preferred embodiments. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

10: Distributed File System 110: Client
120: metadata server 130: data server

Claims (1)

A metadata server for managing metadata information of files, and managing metadata information for snapshot files at a file level; And
A storage unit for storing and managing data of the file in units of chunks and storing and managing the delta chunks of the snapshot files with respect to a chunk of the original files and managing input and output of the original files or the snapshot files; A data server;
/ RTI >

Images