CN1834956A - Processing of multiroute processing element data - Google Patents
Processing of multiroute processing element data Download PDFInfo
- Publication number
- CN1834956A CN1834956A CN 200510055299 CN200510055299A CN1834956A CN 1834956 A CN1834956 A CN 1834956A CN 200510055299 CN200510055299 CN 200510055299 CN 200510055299 A CN200510055299 A CN 200510055299A CN 1834956 A CN1834956 A CN 1834956A
- Authority
- CN
- China
- Prior art keywords
- metadata
- file
- request
- service
- service thread
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
The invention discloses a multithreading metadata processing method, where a client end sends metadata request and data request of filer service to metadata server and data server, respectively; metadata service process in the metadata server controls plural file service threads to process the metadata request. And it improves extendibility of a machine group system and simplifies structure of a storage server, and strengthens stability of the whole machine group file system and ability of the machine group file system to process read-write operation. And it raises CPU utilization ratio of the metadata server and can support concurrent accessing of more client ends. And it effectively solves the shared file processing problem, and assures metadata consistency of shared files and increases throughput of threads processing metadata requests.
Description
Technical field
The present invention relates to a kind of disposal route of multithreading metadata, be meant a kind ofly in cluster file system especially, adopt the method handled of multifile service thread, belong to computer information technology the metadata of file.
Background technology
The treatment capacity of data is very big in network file system(NFS) (Network File System is called for short NFS), in order to improve the readwrite bandwidth of network file system(NFS), the metadata of file and the actual storage data of file separately need be handled.Because NFS has only a server, this server should be handled the metadata request of client, handles the request of data of client again.When concurrent client terminal quantity during greater than some, for example: 32, the readwrite bandwidth of this server will sharply descend, and therefore, the extendability of NFS is very poor.
A kind of approach that addresses the above problem is that the request with client is divided into metadata request and request of data, respectively metadata request and request of data is handled.But in order to guarantee the consistance of metadata, prior art all adopts the mode of one process to come the process metadata request, can influence the performance of the processing power of the server with many CPU like this, has reduced the throughput of meta data server.
Cluster file system (Cluster File System is called for short CFS) is the ingredient of high-performance server, is used for solving the handling problem of the intensive I/O (INPUT/OUTPUT is called for short I/O) of extensive science calculating.In the science computing environment of I/O intensity, the read-write intensity of file is very big.In order to improve the readwrite bandwidth of CFS, technically, CFS need adopt the above-mentioned mode that file metadata and file actual storage data are separately handled.In CFS, the metadata of file is handled by meta data server, and the actual storage data of file are handled by storage server.Because the metadata of file is the description of file attribute, therefore, must guarantee the consistance of metadata.In view of this, the single service processes of general employing of meta data server comes file metadata is handled, and the metadata service processes responds all services request by the mode of sequential processes, therefore, can guarantee the consistance of metadata.But this processing mode is when the quantity of client is increased to a certain degree in a group of planes, for example: 64,128 etc., and the bottleneck that single-threaded meta data server has just become a large amount of metadata to handle.
Summary of the invention
Fundamental purpose of the present invention provides a kind of method of multithreading data processing, solve the bottleneck problem that single-threaded meta data server runs in the prior art when process metadata, guarantee when metadata is shared in the multithreading processing, can guarantee the consistance of metadata simultaneously.
Purpose of the present invention realizes by the following technical solutions:
A kind of disposal route of multithreading metadata, when client sent the file service request, the metadata request with file service sent to meta data server respectively, and the request of data of file service sends to data server; Metadata service processes in the described meta data server is controlled a plurality of file service threads the metadata request that is received is handled;
The processing that the metadata service processes is controlled a plurality of file service threads comprises:
Step 10: the metadata service processes detects whether receive the metadata request that client sends;
Step 11: if do not have, execution in step 10; Otherwise starting the file service thread that is in idle condition handles metadata request; Execution in step 10;
The processing that the file service thread carries out metadata request comprises:
Step 20:, generate the treatment state value of processed file according to the unique number of the pairing processed file of metadata request;
Step 21:, then this treatment state value is stored in treatment state value memory block if in treatment state value memory block, do not preserve this treatment state value; Set up the metadata request formation, be used to preserve the follow-up metadata request of the metadata request of current processed file; Otherwise execution in step 25;
Step 22: processed file is handled accordingly according to current processed metadata request;
Step 23: if also have follow-up metadata request in the metadata request formation of processed file, the follow-up metadata request of in the metadata service processes is initiated all follow-up metadata request that request queue preserves, preserving at first then; Execution in step 26;
Step 24:, then delete the treatment state value of this processed file, execution in step 26 from treatment state value memory block if do not have follow-up metadata request in the metadata request formation of processed file;
Step 25: be saved in metadata request in the metadata request formation of processed file as follow-up metadata request;
Step 26: finish this document service thread, and in the formation of idle file service thread, add this document service thread.
In order to make a plurality of file service threads among the present invention metadata Processing tasks of can balancedly loading, the metadata service processes among the present invention adopts round robin to start a plurality of file service threads metadata request is handled; Specifically comprise:
The metadata service processes is set up an idle file service thread formation simultaneously when creating described a plurality of file service thread, when the file service thread is in idle condition, it is recorded among this idle file service thread formation successively;
When the metadata service processes starts a file service thread, if also preserve idle file service thread in the formation of idle file service thread, then always startup is arranged in first idle file service thread in the formation of idle file service thread, and the file service thread that is activated is deleted from the formation of described idle file service thread.
The present invention compared with prior art has following advantage:
At first, the file service request of client is divided into metadata request and request of data, uses different servers to handle respectively, improved the extensibility of Network of Workstation two class requests; Metadata request is peeled off, simplified the structure of storage server, from designing the stability that strengthened whole cluster file system, having strengthened the processing power of cluster file system read-write operation.
The present invention adopts the request of multithreading process metadata, has improved the utilization factor of meta data server CPU, can support the concurrent visit of more client.
The present invention adopts the treatment state value of processed file to identify the state of processed file, and the handling problem that has solved shared file has effectively guaranteed the consistance of shared file metadata.The present invention uses the metadata request formation, has improved the throughput of thread process metadata request.
Description of drawings
The synoptic diagram that Fig. 1 peels off the metadata services request for the present invention;
Fig. 2 is the processing flow chart of the metadata service processes of the many service threads of the present invention;
Fig. 3 is the file inode message processing flow figure of file service thread of the present invention;
Fig. 4 is the process flow diagram of file service thread process metadata request of the present invention formation.
Embodiment
The present invention is described in further detail below in conjunction with accompanying drawing and specific embodiment:
Client of the present invention was classified this document services request earlier before sending the file service request to server, and metadata services request and request of data are peeled off.Because when user end to server sends the file service request, itself is to know that this request belongs to metadata request or belongs to request of data, therefore, metadata request and request of data separately can be sent, metadata request is issued meta data server go to handle, go to handle and request of data is issued data server.
Referring to Fig. 1, client can be separated the metadata operation request in the cluster file system server operation, send to special meta data server and handle, and the data storage of file then sends to storage server and goes to handle.
Referring to Fig. 2, metadata service processes of the present invention is after startup and initialization, at first will create the worker thread pond of a file metadata service, creating in this worker thread pond has a plurality of file service threads, is used to handle the various metadata operation requests that client sends; After creating the worker thread pond, this metadata service processes is responsible for finishing following task:
1, monitors whether metadata request is arranged; So-called monitoring is meant that the metadata service processes detects the metadata request that client sends by a monitoring of visit formation, monitors the solicited message that in store client sends in the formation, need handle at this.
If 2 have metadata request, the metadata service processes adopts rotation therapy to carry out Task Distribution according to the state of All Files service thread.In fact the distribution here is meant: start a file service thread that is in idle condition, make its response and handle the corresponding metadata request.If there is not metadata request, the metadata service processes then continues to monitor.
Be reciprocity fully between the All Files service thread that the metadata service processes is created, after a metadata services request arrived, the metadata service processes can be sought a file service thread that is in idle condition this metadata services request is handled.Below be the example of a metadata services request of a file service thread process:
Referring to Fig. 3, Fig. 4,, when beginning to handle a metadata request,, generate the treatment state value of this processed file before this according to the unique number of the pairing processed file of this metadata request when a file service thread is started by the metadata service processes; This state value is commonly referred to as metadata attributes record (inode), is used for control visit shared file.This state value that is called as inode is that each file all has a recorded information of describing this document self attributes, comprises contents such as the length of describing this file, creation-time in this recorded information.
When a plurality of clients need simultaneously a shared file to be operated, need utilize above-mentioned inode that these operations are controlled, make at a time to allow a client that this shared file is operated.Concrete method can be: when a client is made amendment to shared file, the inode of this document is set to represent just at processed state value, when other clients are sent metadata request, make that other file service thread at first detected this inode and whether is set to represent that this document is in processed state when metadata service processes startup alternative document service thread was handled it.If belong to this situation, other file service thread will automatically be hung up the metadata request of its processing, is set to represent that up to this inode this document is in not processed state.
In this example, management for convenience, above-mentioned inode can be stored in a memory block, and these leave in the memory block state value in and have constituted an inode set, and this inode set then can be Hash (hash) table that an inode with all processed files is a key assignments.
Next, be in above-mentioned treatment state value memory block (hash table), to watch: the inode that whether preserves above-mentioned processed file; If no, then this inode is stored in treatment state value memory block (hash table); Simultaneously, set up the metadata request formation of this processed file, be used to preserve the follow-up metadata request of current processed file; Then, carry out the function of above-mentioned file service thread, described processed file is handled accordingly according to current processed metadata request; After the processing of finishing metadata request, this document service thread watches in the metadata request formation of above-mentioned processed file whether also having follow-up metadata request, if have, the follow-up metadata request that this document service thread is then preserved in all follow-up metadata request that metadata service processes initiation request queue is preserved at first finishes this document service thread then; The follow-up metadata request that the file service thread is preserved in all follow-up metadata request that metadata service processes initiation request queue is preserved at first, make the metadata service processes can start other a file service thread in view of the above, handle this follow-up metadata request.
If there is not follow-up metadata request in the metadata request formation, then from described treatment state value memory block (hash table), after the treatment state value (inode) of this processed file of deletion, finish this document service thread.
If in treatment state value memory block, preserve the treatment state value (inode) of above-mentioned processed file, illustrate that then this document is by a file service thread process that formerly starts, at this moment, this document service thread only is saved in metadata request in the metadata request formation of this processed file as follow-up metadata request, finishes this document service thread then.
Adopt the treatment scheme of above-mentioned file service thread, can guarantee at a time to have only the metadata of a file service thread process this document, thereby guaranteed the consistance of file metadata.
Among the present invention, adopted a metadata request formation, be used for after a file service thread is through with processing to a shared file, the metadata service processes can start the alternative document service thread to be handled the metadata request that other follow-up clients send.When a plurality of file service threads are handled a file simultaneously, because the inode that first thread can this file is set to represent that this document is in processed state; Like this, the request of other file service thread will be placed to this metadata request formation and waits for.Referring to Fig. 4, after the metadata request of the intact file of a file service thread process, the metadata request that it can judge whether other waiting for and handling, as do not have, and it will discharge the inode of this document.Otherwise, just be used to start an alternative document service thread processing and waiting pending metadata request to one of metadata service processes transmission.As mentioned above, the metadata service processes can start the file service thread of a free time in the current thread pond, comes first metadata request in the process metadata request queue.
In order to make a plurality of file service threads among the present invention metadata Processing tasks of can balancedly loading, the metadata service processes among the present invention adopts round robin to start a plurality of file service threads metadata request is handled: the metadata service processes adopts round robin to start described a plurality of file service thread described metadata request is handled;
When the metadata service processes when creating described a plurality of file service thread, set up an idle file service thread formation simultaneously, when the file service thread is in idle condition, among its idle file service thread formation that is recorded in successively; When the metadata service processes when starting a file service thread, if also preserve idle file service thread in the formation of described idle file service thread, then always start and be arranged in first idle file service thread in the formation of idle file service thread, simultaneously, the file service thread that is activated is deleted from the formation of described idle file service thread.And when the file service thread finishes processing to metadata request, then oneself is added among the formation of idle file service thread, be activated to prepare next time.
It should be noted that at last: above embodiment only in order to the explanation the present invention and and unrestricted technical scheme described in the invention; Therefore, although this instructions has been described in detail the present invention with reference to each above-mentioned embodiment,, those of ordinary skill in the art should be appreciated that still and can make amendment or be equal to replacement the present invention; And all do not break away from the technical scheme and the improvement thereof of the spirit and scope of the present invention, and it all should be encompassed in the middle of the claim scope of the present invention.
Claims (2)
1, a kind of disposal route of multithreading metadata is characterized in that: when client sent the file service request, the metadata request with file service sent to meta data server respectively, and the request of data of file service sends to data server; Metadata service processes in the described meta data server is controlled a plurality of file service threads the metadata request that is received is handled;
The processing that described metadata service processes is controlled a plurality of file service threads comprises:
Step 10: the metadata service processes detects whether receive the metadata request that client sends;
Step 11: if do not have, execution in step 10; Otherwise starting the file service thread that is in idle condition handles described metadata request; Execution in step 10;
The processing that described file service thread carries out the metadata request that is received comprises:
Step 20:, generate the treatment state value of described processed file according to the unique number of the pairing processed file of metadata request;
Step 21:, then this treatment state value is stored in treatment state value memory block if in treatment state value memory block, do not preserve this treatment state value; Set up the metadata request formation, be used to preserve the follow-up metadata request of current processed file; Otherwise execution in step 25;
Step 22: described processed file is handled accordingly according to current processed metadata request;
Step 23: if also have follow-up metadata request in the metadata request formation of processed file, the follow-up metadata request of in described metadata service processes is initiated all follow-up metadata request that the described request formation preserves, preserving at first then; Execution in step 26;
Step 24: if do not have follow-up metadata request in the metadata request formation of processed file, the treatment state value of deleting this processed file then, execution in step 26 from described treatment state value memory block;
Step 25: be saved in described metadata request in the metadata request formation of processed file as follow-up metadata request;
Step 26: finish this document service thread, and in the formation of idle file service thread, add this document service thread.
2, the disposal route of multithreading metadata according to claim 1 is characterized in that: in the described step 11, adopt round robin when the metadata service processes starts the file service thread that is in idle condition; Specifically comprise:
Described metadata service processes is set up an idle file service thread formation simultaneously when creating described a plurality of file service thread, when the file service thread is in idle condition, it is recorded among the formation of described idle file service thread successively;
Described metadata service processes is when starting a file service thread, if also preserve idle file service thread in the formation of described idle file service thread, then always startup is arranged in first idle file service thread in the formation of described idle file service thread, and the file service thread that is activated is deleted from the formation of described idle file service thread.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2005100552991A CN100375093C (en) | 2005-03-18 | 2005-03-18 | Processing of multiroute processing element data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2005100552991A CN100375093C (en) | 2005-03-18 | 2005-03-18 | Processing of multiroute processing element data |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1834956A true CN1834956A (en) | 2006-09-20 |
| CN100375093C CN100375093C (en) | 2008-03-12 |
Family
ID=37002703
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2005100552991A Expired - Fee Related CN100375093C (en) | 2005-03-18 | 2005-03-18 | Processing of multiroute processing element data |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100375093C (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102156637A (en) * | 2011-05-04 | 2011-08-17 | 中国人民解放军国防科学技术大学 | Vector crossing multithread processing method and vector crossing multithread microprocessor |
| CN101488924B (en) * | 2009-02-16 | 2011-11-16 | 成都市华为赛门铁克科技有限公司 | Metadata modification method and metadata server |
| CN102469064A (en) * | 2010-11-03 | 2012-05-23 | 中兴通讯股份有限公司 | Method for implementing communication and communication equipment |
| CN102567089A (en) * | 2011-10-25 | 2012-07-11 | 曙光信息产业(北京)有限公司 | Design method for thread pool of metadata server in distributed file system |
| CN102750322A (en) * | 2012-05-22 | 2012-10-24 | 中国科学院计算技术研究所 | Method and system for guaranteeing distributed metadata consistency for cluster file system |
| CN104104731A (en) * | 2014-07-28 | 2014-10-15 | 浪潮(北京)电子信息产业有限公司 | Method and device for maintaining data consistency |
| CN105353987A (en) * | 2015-11-13 | 2016-02-24 | 曙光信息产业股份有限公司 | File processing method and device |
| CN105389399A (en) * | 2015-12-25 | 2016-03-09 | 北京奇虎科技有限公司 | Method and device for managing meta-information of database cluster |
| WO2017028719A1 (en) * | 2015-08-19 | 2017-02-23 | 阿里巴巴集团控股有限公司 | Metadata output method, client side, and metadata server |
| CN106873906A (en) * | 2017-01-04 | 2017-06-20 | 北京百度网讯科技有限公司 | Method and apparatus for managing metamessage |
| CN107205049A (en) * | 2017-07-28 | 2017-09-26 | 郑州云海信息技术有限公司 | A kind of network attached storage method and storage service apparatus |
| CN110888844A (en) * | 2019-11-22 | 2020-03-17 | 浪潮电子信息产业股份有限公司 | Data deleting method, system, equipment and computer readable storage medium |
| CN111355777A (en) * | 2020-02-14 | 2020-06-30 | 西安奥卡云数据科技有限公司 | Management method and device of distributed file system and server |
| CN115086328A (en) * | 2022-04-30 | 2022-09-20 | 济南浪潮数据技术有限公司 | Metadata service business processing method, device, equipment and medium |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8010558B2 (en) * | 2001-06-05 | 2011-08-30 | Silicon Graphics International | Relocation of metadata server with outstanding DMAPI requests |
| US20030028514A1 (en) * | 2001-06-05 | 2003-02-06 | Lord Stephen Philip | Extended attribute caching in clustered filesystem |
| US6768993B2 (en) * | 2001-06-28 | 2004-07-27 | International Business Machines Corporation | System and method for file system cooperation in a multi-threaded environment |
| CN100504854C (en) * | 2003-01-14 | 2009-06-24 | 联想(北京)有限公司 | Document management method |
| CN100498766C (en) * | 2003-12-02 | 2009-06-10 | 天津曙光计算机产业有限公司 | Mass file management system and method based on database |
-
2005
- 2005-03-18 CN CNB2005100552991A patent/CN100375093C/en not_active Expired - Fee Related
Cited By (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101488924B (en) * | 2009-02-16 | 2011-11-16 | 成都市华为赛门铁克科技有限公司 | Metadata modification method and metadata server |
| CN102469064A (en) * | 2010-11-03 | 2012-05-23 | 中兴通讯股份有限公司 | Method for implementing communication and communication equipment |
| CN102469064B (en) * | 2010-11-03 | 2016-05-11 | 中兴通讯股份有限公司 | Realization Method of Communication and communication equipment |
| CN102156637A (en) * | 2011-05-04 | 2011-08-17 | 中国人民解放军国防科学技术大学 | Vector crossing multithread processing method and vector crossing multithread microprocessor |
| CN102567089A (en) * | 2011-10-25 | 2012-07-11 | 曙光信息产业(北京)有限公司 | Design method for thread pool of metadata server in distributed file system |
| CN102750322A (en) * | 2012-05-22 | 2012-10-24 | 中国科学院计算技术研究所 | Method and system for guaranteeing distributed metadata consistency for cluster file system |
| CN102750322B (en) * | 2012-05-22 | 2014-11-05 | 中国科学院计算技术研究所 | Method and system for guaranteeing distributed metadata consistency for cluster file system |
| CN104104731A (en) * | 2014-07-28 | 2014-10-15 | 浪潮(北京)电子信息产业有限公司 | Method and device for maintaining data consistency |
| WO2017028719A1 (en) * | 2015-08-19 | 2017-02-23 | 阿里巴巴集团控股有限公司 | Metadata output method, client side, and metadata server |
| CN105353987A (en) * | 2015-11-13 | 2016-02-24 | 曙光信息产业股份有限公司 | File processing method and device |
| CN105389399A (en) * | 2015-12-25 | 2016-03-09 | 北京奇虎科技有限公司 | Method and device for managing meta-information of database cluster |
| CN106873906A (en) * | 2017-01-04 | 2017-06-20 | 北京百度网讯科技有限公司 | Method and apparatus for managing metamessage |
| CN107205049A (en) * | 2017-07-28 | 2017-09-26 | 郑州云海信息技术有限公司 | A kind of network attached storage method and storage service apparatus |
| CN107205049B (en) * | 2017-07-28 | 2020-06-16 | 苏州浪潮智能科技有限公司 | Network attachment storage method and storage service device |
| CN110888844A (en) * | 2019-11-22 | 2020-03-17 | 浪潮电子信息产业股份有限公司 | Data deleting method, system, equipment and computer readable storage medium |
| CN110888844B (en) * | 2019-11-22 | 2023-03-21 | 浪潮电子信息产业股份有限公司 | Data deleting method, system, equipment and computer readable storage medium |
| CN111355777A (en) * | 2020-02-14 | 2020-06-30 | 西安奥卡云数据科技有限公司 | Management method and device of distributed file system and server |
| CN115086328A (en) * | 2022-04-30 | 2022-09-20 | 济南浪潮数据技术有限公司 | Metadata service business processing method, device, equipment and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100375093C (en) | 2008-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1834956A (en) | Processing of multiroute processing element data | |
| CN111480154B (en) | Method, system, and medium for batch data ingestion | |
| Davidson et al. | Optimizing shuffle performance in spark | |
| US9223820B2 (en) | Partitioning data for parallel processing | |
| US20240004834A1 (en) | Directory structure for a distributed storage system | |
| US6442661B1 (en) | Self-tuning memory management for computer systems | |
| US8495108B2 (en) | Virtual node subpool management | |
| CN100345143C (en) | Method and apparatus for data processing | |
| US20130218934A1 (en) | Method for directory entries split and merge in distributed file system | |
| US20110078467A1 (en) | Reducing energy consumption in a computing cluster | |
| US11822521B2 (en) | Associating application-specific methods with tables used for data storage | |
| CN113377868B (en) | Offline storage system based on distributed KV database | |
| US9836516B2 (en) | Parallel scanners for log based replication | |
| JP2005092875A (en) | System and method for increasing data throughput by using thread scheduling | |
| CN103412786A (en) | High performance server architecture system and data processing method thereof | |
| CN1293493C (en) | Computer group file service system and its input output treatment method | |
| US10853140B2 (en) | Slab memory allocator with dynamic buffer resizing | |
| CN1602480A (en) | Managing storage resources attached to a data network | |
| US20150169367A1 (en) | System and method for supporting adaptive busy wait in a computing environment | |
| EP2951691A1 (en) | System and method for supporting work sharing muxing in a cluster | |
| US8918555B1 (en) | Adaptive and prioritized replication scheduling in storage clusters | |
| US9503353B1 (en) | Dynamic cross protocol tuner | |
| US11064020B2 (en) | Connection load distribution in distributed object storage systems | |
| CN113342839A (en) | Data processing method and device, terminal equipment and storage medium | |
| Abead et al. | An efficient replication technique for hadoop distributed file system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080312 Termination date: 20210318 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |