Record organizational method and record organizational structure

Abstract

The invention discloses a record organizational method and a record organizational structure, wherein the record organizational method comprises the steps that an unique identifier is assigned for each type of records; a data file and a metadata file corresponding to each type of records are created in the corresponding disk file, and the data file of each type of records corresponds to one disk file; and only continuous re-appending write operation can be carried out to the data files. Through the technical scheme in the invention, the performance of a metadata server under high pressure can be improved, and the extendibility is good.

Description

technical field [0001] The present invention relates to a storage system of a data server, more specifically, to a record organization method and a record organization structure. Background technique [0002] In parallel storage systems, it is often necessary to record some auxiliary records or indexes. For example, when a disk is damaged, in order to quickly restore the data on it, it is necessary to record which objects exist on the disk. This requires adding records when creating files and deleting corresponding records when deleting files. In addition, since the data server has multiple copies, it is also necessary to record inconsistent objects, and delete the corresponding records after the repair is completed. In order to improve the metadata performance, the deletion adopts an asynchronous method, that is, after setting the delete flag on the metadata server, the client is responded to, and the real inode (index node) and data removal are handled by the garbage coll...

AI Technical Summary

Problems solved by technology

[0005] 1) It is not conducive to expansion: because the recorded metadata is the inode of the file system, and the reserved fields of the inode are limited, when the attributes that need to be added to the recorded metadata exceed the limit, it will be difficult to add (modified as a file for auxiliary information) The most important structural inode of system metadata is less desirable);

[0006] 2) Waste of space: Since each record is recorded as a dentry item, all attributes of the dentry item will of course be inherited, but not all attributes are necessary for this record;

[0007] 3) It is also the most serious defect of this method. This implementation method will affect the application performance of the log. When the metadata pressure is relatively high, it will become the bottleneck of the system and affect the overall performance: the goal pursued by the metadata extension hash is that the dentry item is in the Each hash bucket is as uniform as possible, and the amount of these auxiliary records is very large (because each file in the ParaStor file system uses multiple disks). When the extended hash is relatively large, the log application will cause the disk head to scan back and forth. This will greatly reduce the application efficiency. When the log pressure reaches a certain level, the metadata log submission request will be temporarily rejected, which will affect the performance of the entire metadata.

Images