CN109885552A - The metadata dynamic management approach and distributed file system of distributed file system - Google Patents
The metadata dynamic management approach and distributed file system of distributed file system Download PDFInfo
- Publication number
- CN109885552A CN109885552A CN201910123320.9A CN201910123320A CN109885552A CN 109885552 A CN109885552 A CN 109885552A CN 201910123320 A CN201910123320 A CN 201910123320A CN 109885552 A CN109885552 A CN 109885552A
- Authority
- CN
- China
- Prior art keywords
- metadata
- server
- preposition
- server cluster
- cluster
- 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
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a kind of metadata dynamic management approach of distributed file system, include the following steps: that S1. selects multiple servers as front server to constitute preposition metadata server cluster in metadata server cluster, remaining meta data server in metadata server cluster constitutes non-preposition metadata server cluster；All metadata read-write requests that client is initiated, are uniformly processed, and the metadata in write request is only stored in the memory of preposition metadata server cluster by preposition metadata server cluster；S2. start front server；S3. the metadata read-write requests of client are handled.By means of the invention it is possible to provide the high speed access to metadata, the load to distributed system is reduced, realizes preferable load balancing.
Description
Technical field
The present invention relates to metadata dynamic management approach and computer systems, are based on distributed document more particularly, to one kind
The metadata dynamic management approach and distributed file system of system.
Background technique
With the continuous development of internet information technology, storage system is just as the increase of data volume becomes more and more important.Point
The characteristics of cloth file system is with high fault tolerance, high concurrent, enhanced scalability, the trend of the exponential growth of responsive message, obtains
The attention of storage manufacturer and practitioner is arrived.
Two class data are mainly managed in distributed file system, one kind is the data of user, and one kind is referred to as metadata, i.e.,
For managing and indexing the data of user data.The accessing characteristic of the data of user stores intensity partially, and the access of metadata
The inclined computation-intensive of feature.So in general, these two types of Dynamic data exchanges can be managed and be stored by distributed file system, wherein
The component of storage user data is known as data server, and the component for storing metadata is known as meta data server.
It is distributed in order to make entire distributed file system that there is stronger fault-tolerant ability and higher parallel access capacity
File system is respectively using multiple nodes building data server cluster and metadata server cluster.Due to the frequency to metadata
The problem of numerous access, dynamic load unevenness often occurs, and causes system response time slack-off or even to will appear system unstable
Problem.
To solve the above problems, being capable of providing the high speed to metadata the present invention provides a kind of distributed file system
Access, and can be realized preferable load balancing.
Summary of the invention
Purpose to realize the present invention, is achieved using following technical scheme:
A kind of metadata dynamic management approach of distributed file system, this method comprises the following steps:
S1. select multiple servers as front server to constitute preposition metadata clothes in metadata server cluster
It is engaged in device cluster, remaining meta data server in metadata server cluster constitutes non-preposition metadata server cluster；Client
All metadata read-write requests initiated are held, are uniformly processed by preposition metadata server cluster, and the member in write request
Data are only stored in the memory of preposition metadata server cluster；
S2. start front server；
S3. the metadata read-write requests of client are handled.
The metadata dynamic management approach, in which: step S2 includes:
S201. it pre-processes: setting configuration file for front server
S202. front server initializes:
According to configuration file, every front server and other front servers communicate with each other and are automatically composed preposition metadata
Server cluster.
The metadata dynamic management approach, in which: include two class mailing addresses and port, Yi Leiyong in configuration file
Communication between front server, the another kind of client communication for user side.
The metadata dynamic management approach, in which: further include step S203: front server elects main preposition clothes
Business device.
The metadata dynamic management approach, in which: step S3 processing client metadata read-write requests include:
S301. front server handles metadata write request: the connection of client and any one front server, initiates
Metadata write request, after preposition metadata server cluster receives the metadata write request of client initiation, according to following streams
Journey processing:
If client connection is main front server, write operation is carried out by main front server；
If client connection is not main front server, forwards the metadata to write automatically by the front server and ask
It asks to main front server and carries out write operation.
The metadata dynamic management approach, in which: after main front server receives write request, first by write request
In metadata write-in where server memory in, then the metadata is written in the memory of other front servers,
The half for being greater than total front server quantity until successful front server quantity is written；Main front server is returned to client
It is written back into successful result.
The metadata dynamic management approach, in which: preposition metadata server cluster is after completing write request, record
One log, the content of this log include the catalogue of metadata, file path, modification content, modification time.
The metadata dynamic management approach, in which: step S3 processing client metadata read-write requests include:
S302. front server processing elements data read request: client connect and issues with any one front server
Metadata read request, front server is in the read request for receiving client, according to following flow processings: receiving the reading and asks
The front server asked is communicated by preposition metadata server cluster and determines whether the client metadata to be read all deposits
Storage is in preposition metadata server cluster, if the client metadata to be read is stored entirely in preposition meta data server
In cluster, then the front server directly reads the metadata from preposition metadata server cluster and returns to client
End.
The metadata dynamic management approach, in which: if before the client metadata to be read is not stored in completely
It sets in metadata server cluster, the front server for receiving the read request sends read request to non-preposition meta data server
Cluster, non-preposition metadata server cluster metadata needed for transferring client in hard disk, and the metadata is returned
Client is returned to the front server for receiving the read request, and by the front server
The metadata dynamic management approach, in which: if the client meta-data section to be read be stored in it is preposition
In metadata server cluster, front server sends read request to preposition metadata server cluster and non-preposition first number first
According to server cluster, the front server in preposition metadata server cluster, which returns to required part metadata, to be received
The front server of the read request, non-preposition metadata server cluster member number in part needed for transferring client in hard disk
According to, and the metadata is returned to the front server for receiving the read request；The front server for receiving the read request will
Two parts metadata received carries out polymerization processing, and metadata is returned to client after processing；
The metadata dynamic management approach, wherein further include: the preposition metadata server cluster of S4. is to non-preposition member
Data server cluster synchronizes latest data: predetermined instant of the main front server in per consecutive days parses this front server note
The log of record only retains newest metadata log for the same catalogue, file, realizes log compression；
After parsing, main front server starts new synchronizing thread, according to compressed log successively to non-preposition
Write request is initiated in metadata server cluster, and newest metadata is synchronized to the hard disk of non-preposition metadata server cluster
In.
The metadata dynamic management approach, in which: after main front server completes the synchronizing an of metadata, i.e., by
Step deletes the metadata stored in each server memory in each preposition meta data server, until deleting whole first numbers
According to.
The metadata dynamic management approach, in which: preposition metadata server cluster is when handling read-write requests, note
Record the access load of each catalogue, file.
The metadata dynamic management approach, in which: access load is as follows: one time read request is calculated as 1, and primary modification is asked
It asks and is calculated as 2, a request to create is calculated as 3, and one time removal request is calculated as 2.
The metadata dynamic management approach, in which: the load factor of each file is equal to: read request number * 1+ writes
Request number of times * 2+ request to create number * 3+ removal request number * 2；The load factor of each catalogue is equal to: read request number * 1+
Write request number * 2+ request to create number * 3+ removal request number * 2, and plus all catalogues under the catalogue, file load because
The summation of son.
The metadata dynamic management approach, wherein further including the name that S5. repartitions metadata server cluster
Space: main front server is calculated the load factor of each catalogue, file, and with saved in main front server upper one
The load factor of secondary calculating is averaged；And according to this load factor average, identify that load factor is more than pre-set negative
Catalogue, the file of threshold value are carried, and corresponding catalogue, the metadata of file more than load threshold is subjected to weight by front server
It is new to divide.
The metadata dynamic management approach, wherein division mode is as follows:
If 1) there are multiple subdirectories under certain catalogue, and each subdirectory load factor is approximate, then the fractionation of each subdirectory is deposited
Storage is in different metadata server cluster servers；
If 2) have multiple subdirectories under certain catalogue, and each subdirectory load factor difference is larger, then to the high load factor
Subdirectory execute step 1；
If 3) only one subdirectory under certain catalogue, the fractionation of each subdirectory is stored in different meta data servers
In cluster server；
If 4) have multiple files under certain catalogue, and each file load factor is approximate, then is stored in each file declustering not
In same metadata server cluster server；
If 5) only one file under certain catalogue, this document metadata is stored in preposition member by main front server
In the memory of data server cluster, while the maximum keep alive time of the metadata is set.
A kind of distributed file system, including metadata server cluster, in which: the metadata server cluster is by more
Platform meta data server composition, the metadata server cluster include preposition metadata server cluster and non-preposition first number
According to server cluster；All metadata read-write requests that client is initiated, it is unified by preposition metadata server cluster
Reason, and the metadata in write request is only stored in the memory of preposition metadata server cluster.
The distributed file system, in which: the system execute as above one of described in metadata dynamic management approach.
The distributed file system, in which: the distributed file system further includes data server cluster.
Detailed description of the invention
Fig. 1 is that the overall architecture of distributed file system of the present invention illustrates intention.
Specific embodiment
As shown in Figure 1, distributed file system of the invention includes metadata server cluster, metadata server cluster
It is made of more meta data servers, the metadata dynamic management approach includes the following steps:
S1. select N platform (wherein: N is greater than 3 odd number) server as preposition service in metadata server cluster
For device to constitute preposition metadata server cluster, the front server is stored with metadata in memory；What client was initiated
All metadata read-write requests, are uniformly processed by preposition metadata server cluster, and the metadata in write request is only protected
There are in the memory of preposition metadata server cluster；The front server be used for execute client initiation metadata read,
Write request.The selection rule of front server is to select memory size in the N platform server of top N, to improve to read-write requests
Response speed.The server in addition to front server in metadata server cluster is known as non-front server, by non-
The cluster that front server is constituted is known as non-preposition metadata server cluster.
S2. start front server:
S201. it pre-processes: setting configuration file for front server.It include two class mailing addresses and end in configuration file
Mouthful, heartbeat detection, health examination, data of the one kind between front server are synchronous (hereinafter referred to as " peer communication "),
It is another kind of to be used to be connected with the client of user side, for handling read-write requests (hereinafter referred to as " client communication ")；
S202. front server initializes:
According to configuration file, every front server is communicated with each other with other front servers, and by distributed consistent
Property agreement (Raft agreement), is automatically composed preposition metadata server cluster；
S203. front server elects main front server using Raft agreement；
S3. front server processing elements reading and writing data is requested
S301. front server handles metadata write request:
Client is connect with the client mailing address of any one front server and port, and initiation metadata, which is write, asks
It asks, after preposition metadata server cluster receives the metadata write request of client initiation, according to following flow processings:
If client connection is main front server, write operation is carried out by main front server；
If client connection is not main front server, forwards the metadata to write automatically by the front server and ask
It asks to main front server and carries out actual write operation；
After main front server receives write request, first by the memory of server where the metadata write-in in write request
In, it is then written in the memory of other front servers by peer communication, until successful front server quantity is written
Greater than the half (following " the most of principles " in Raft agreement) of total front server quantity, can deposit through the above way
More points of copies for storing up a data, enhance the disaster tolerance of distributed system, prevent data caused by damaging because of certain server
It loses；
Main front server is returned to client is written successful result realization distributed consensus；
For preposition metadata server cluster after completing write request, main front server will record a log, this day
Contents (referred to as " the journal such as catalogue, file path, modification content, the modification time of metadata are had recorded in will in detail
log")；
S302. front server processing elements data read request:
Client can connect with the client mailing address of any one front server and port and issue metadata
Read request.Front server is in the read request for receiving client, according to following flow processings:
The front server that read request can be received the read request by any one is responsible for processing, before being forwarded to master
Set server process；
The front server for receiving the read request communicates determine whether the client metadata to be read is complete by peer
Portion is stored in the memory of preposition metadata server cluster, if the client metadata to be read is stored entirely in preposition member
In data server cluster, then the front server directly reads the metadata simultaneously from preposition metadata server cluster
Return to client；
If the client metadata to be read is not stored in completely in the memory of preposition metadata server cluster,
The front server for receiving the read request sends read request to non-preposition metadata server cluster, non-preposition Metadata Service
Device cluster metadata needed for transferring client in hard disk, and the metadata is returned to and receives the preposition of the read request
Server, front server saves the metadata in memory, and returns to client by the front server；
If the client meta-data section to be read is stored in preposition metadata server cluster, preposition service
Device sends read request to preposition metadata server cluster first, then sends read request to non-preposition meta data server collection
Group, the front server in preposition metadata server cluster, which returns to required part metadata, receives the read request
Front server, non-preposition metadata server cluster part metadata needed for transferring client in hard disk, and will be described
Metadata returns to the front server for receiving the read request；It will finally be received by receiving the front server of the read request
Two parts metadata carries out polymerization processing, and metadata is returned to client after processing；
S4. preposition metadata server cluster synchronizes latest data to metadata server cluster:
Include the newest metadata information of the consecutive days in preposition metadata server cluster, needs per consecutive days to first number
According to synchronous in server cluster.The disk that on the one hand can be synchronized to newest metadata in metadata server cluster in this way
It is interior, storage that can be safer；It on the other hand is also metadata write request of the recycling memory source to handle next consecutive days.Number
It is handled according to synchronous according to following below scheme:
There is independent parsing thread in main front server, start in the particular moment (such as 24 o'clock sharps) of per consecutive days,
The journal log for parsing this main front server record, parses journal log according to time inverted order, i.e., for same
Catalogue, file only retain newest metadata log, to realize journal log compression function；
After parsing, main front server starts new synchronizing thread, according to compressed journal log successively to
Write request is initiated in non-preposition metadata server cluster, newest metadata is synchronized to non-preposition metadata server cluster
In, i.e., non-preposition metadata server cluster is by newest metadata updates into hard disk；
After main front server completes the synchronizing an of metadata, i.e., gradually delete each in preposition metadata server cluster
Metadata stored in server memory, to recycle memory source, until deleting whole metadata；
S5. the NameSpace of metadata server cluster is repartitioned:
Preposition metadata server cluster will record the access load of each catalogue, file when handling read-write requests:
Since preposition metadata server cluster handles all metadata read-write requests, so it is asked in execution reading and writing
Ask the access load that each catalogue, file are recorded in the memory of the front server (including modification, creation and removal request).It is negative
It is as follows to carry factor calculation formula:
One time read request is calculated as: 1
Primary modification request is calculated as: 2
One time request to create is calculated as: 3
One time removal request is calculated as: 2
The load factor of each file is equal to: read request number * 1+ write request number * 2+ request to create number * 3+ is deleted
Request number of times * 2
The load factor of each catalogue is equal to: catalogue read request number * 1+ catalogue write request number * 2+ catalogue wound
Request number of times * 3+ directory delete request number of times * 2 is built, in addition all catalogues, the summation of the file load factor in the catalogue.
After the completion of S4 step, main front server is calculated each according to above-mentioned access load factor calculation formula
The load factor of catalogue, file, and be averaged with the last load factor calculated saved in main front server.And according to
This load factor average identifies that load factor is more than the catalogue of pre-set load threshold, file, and by preposition service
Device is repartitioned corresponding more than the catalogue of load threshold, the metadata of file, and wherein division mode is as follows:
1. if then the fractionation of each subdirectory deposited have multiple subdirectories under certain catalogue, and each subdirectory load factor is approximate
Storage is in different metadata server cluster servers；
If 2. there is multiple subdirectories under certain catalogue, and each subdirectory load factor difference it is larger (such as difference 10 times with
On), then step 1 is executed to the subdirectory of the high load factor；
3. if only one subdirectory under certain catalogue, is stored in different meta data servers for the fractionation of each subdirectory
In cluster server；
4. if having multiple files under certain catalogue, and each file load factor is approximate, then is stored in each file declustering not
In same metadata server cluster server；
5. if only one file under certain catalogue, is stored in preposition member for this document metadata by main front server
In the memory of data server cluster, while the maximum keep alive time of the metadata is set, prevents it from permanently occupying preposition first number
According to the memory source of server cluster.
By means of the invention it is possible to provide the high speed access to metadata, the load to distributed system is reduced, is realized preferable
Load balancing.
Claims (4)
1. a kind of metadata dynamic management approach of distributed file system, it is characterised in that this method comprises the following steps:
S1. select multiple servers as front server to constitute preposition meta data server in metadata server cluster
Cluster, remaining meta data server in metadata server cluster constitute non-preposition metadata server cluster；Client hair
All metadata read-write requests risen, are uniformly processed, and the metadata in write request by preposition metadata server cluster
It is only stored in the memory of preposition metadata server cluster；
S2. start front server；
S3. the metadata read-write requests of client are handled.
2. metadata dynamic management approach according to claim 1, it is characterised in that: step S2 includes:
S201. it pre-processes: setting configuration file for front server
S202. front server initializes:
According to configuration file, every front server and other front servers communicate with each other and are automatically composed preposition Metadata Service
Device cluster.
3. metadata dynamic management approach according to claim 2, it is characterised in that: communicated in configuration file comprising two classes
Address and port, one kind is for the communication between front server, the another kind of client communication for user side.
4. metadata dynamic management approach according to claim 2, it is characterised in that: further include step S203: preposition clothes
Business device elects main front server.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910123320.9A CN109885552B (en) | 2019-02-18 | 2019-02-18 | Metadata dynamic management method of distributed file system and distributed file system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910123320.9A CN109885552B (en) | 2019-02-18 | 2019-02-18 | Metadata dynamic management method of distributed file system and distributed file system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109885552A true CN109885552A (en) | 2019-06-14 |
| CN109885552B CN109885552B (en) | 2023-08-18 |
Family
ID=66928324
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910123320.9A Active CN109885552B (en) | 2019-02-18 | 2019-02-18 | Metadata dynamic management method of distributed file system and distributed file system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109885552B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112579543A (en) * | 2020-12-29 | 2021-03-30 | 航天科工网络信息发展有限公司 | Dynamic metadata management method for distributed file system and distributed file system |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101697168A (en) * | 2009-10-22 | 2010-04-21 | 中国科学技术大学 | Method and system for dynamically managing metadata of distributed file system |
| CN102143215A (en) * | 2011-01-20 | 2011-08-03 | 中国人民解放军理工大学 | Network-based PB level cloud storage system and processing method thereof |
| CN102571772A (en) * | 2011-12-26 | 2012-07-11 | 华中科技大学 | Hot spot balancing method for metadata server |
| CN102904949A (en) * | 2012-10-08 | 2013-01-30 | 华中科技大学 | Replica-based dynamic metadata cluster system |
| CN104580536A (en) * | 2015-02-06 | 2015-04-29 | 浪潮电子信息产业股份有限公司 | Metadata cluster load balance realization method |
| CN104978239A (en) * | 2014-04-08 | 2015-10-14 | 重庆邮电大学 | Method, device and system for realizing multi-backup-data dynamic updating |
| CN107070972A (en) * | 2016-12-30 | 2017-08-18 | 中国银联股份有限公司 | A kind of distributed document processing method and processing device |
| US20170272100A1 (en) * | 2016-03-15 | 2017-09-21 | Cloud Crowding Corp. | Distributed Storage System Data Management And Security |
| CN109344122A (en) * | 2018-10-15 | 2019-02-15 | 中山大学 | A kind of distributed meta-data management method and system for creating strategy in advance based on file |
| CN112579543A (en) * | 2020-12-29 | 2021-03-30 | 航天科工网络信息发展有限公司 | Dynamic metadata management method for distributed file system and distributed file system |
-
2019
- 2019-02-18 CN CN201910123320.9A patent/CN109885552B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101697168A (en) * | 2009-10-22 | 2010-04-21 | 中国科学技术大学 | Method and system for dynamically managing metadata of distributed file system |
| CN102143215A (en) * | 2011-01-20 | 2011-08-03 | 中国人民解放军理工大学 | Network-based PB level cloud storage system and processing method thereof |
| CN102571772A (en) * | 2011-12-26 | 2012-07-11 | 华中科技大学 | Hot spot balancing method for metadata server |
| CN102904949A (en) * | 2012-10-08 | 2013-01-30 | 华中科技大学 | Replica-based dynamic metadata cluster system |
| CN104978239A (en) * | 2014-04-08 | 2015-10-14 | 重庆邮电大学 | Method, device and system for realizing multi-backup-data dynamic updating |
| CN104580536A (en) * | 2015-02-06 | 2015-04-29 | 浪潮电子信息产业股份有限公司 | Metadata cluster load balance realization method |
| US20170272100A1 (en) * | 2016-03-15 | 2017-09-21 | Cloud Crowding Corp. | Distributed Storage System Data Management And Security |
| CN107070972A (en) * | 2016-12-30 | 2017-08-18 | 中国银联股份有限公司 | A kind of distributed document processing method and processing device |
| CN109344122A (en) * | 2018-10-15 | 2019-02-15 | 中山大学 | A kind of distributed meta-data management method and system for creating strategy in advance based on file |
| CN112579543A (en) * | 2020-12-29 | 2021-03-30 | 航天科工网络信息发展有限公司 | Dynamic metadata management method for distributed file system and distributed file system |
Non-Patent Citations (2)
| Title |
|---|
| JEHAN-FRANÇOIS PÂRIS ET AL.: "Pirogue, a lighter dynamic version of the Raft distributed consensus algorithm", 《2015 IEEE 34TH INTERNATIONAL PERFORMANCE COMPUTING AND COMMUNICATIONS CONFERENCE (IPCCC)》, pages 1 - 8 * |
| 崔聪祎: "分布式块文件系统元数据管理子系统的设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》, pages 138 - 102 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112579543A (en) * | 2020-12-29 | 2021-03-30 | 航天科工网络信息发展有限公司 | Dynamic metadata management method for distributed file system and distributed file system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109885552B (en) | 2023-08-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8904137B1 (en) | Deduplication system space recycling through inode manipulation | |
| US9547706B2 (en) | Using colocation hints to facilitate accessing a distributed data storage system | |
| US8965840B2 (en) | Automatic synchronization conflict resolution | |
| US10248682B2 (en) | Object storage system capable of performing snapshots, branches and locking | |
| US9239843B2 (en) | Scalable de-duplication for storage systems | |
| JP5722962B2 (en) | Optimize storage performance | |
| US20110153570A1 (en) | Data replication and recovery method in asymmetric clustered distributed file system | |
| CN101272313B (en) | Intermediate device for achieving virtualization of file level, file server system and relay method | |
| CN113377868B (en) | Offline storage system based on distributed KV database | |
| US20160246834A1 (en) | Locking and i/o improvements of systems built with distributed consistent database implementations within an object store | |
| CN104111804A (en) | Distributed file system | |
| CN109522283A (en) | A kind of data de-duplication method and system | |
| CN113360456B (en) | Data archiving method, device, equipment and storage medium | |
| CN112162846B (en) | Transaction processing method, device and computer readable storage medium | |
| JP7038864B2 (en) | Search server centralized storage | |
| CN107181773A (en) | Data storage and data managing method, the equipment of distributed memory system | |
| CN115840731A (en) | File processing method, computing device and computer storage medium | |
| US8612717B2 (en) | Storage system | |
| CN114610680A (en) | Method, device and equipment for managing metadata of distributed file system and storage medium | |
| CN109885552A (en) | The metadata dynamic management approach and distributed file system of distributed file system | |
| WO2015134679A2 (en) | Locking and i/o improvements of systems built with distributed consistent database implementations within an object store | |
| EP3114581A1 (en) | Object storage system capable of performing snapshots, branches and locking | |
| CN112579543A (en) | Dynamic metadata management method for distributed file system and distributed file system | |
| CN115408342A (en) | File processing method and device and electronic equipment | |
| JP2013088920A (en) | Computer system and data management method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 518100 3b06, building 3, area a, Bao'an Internet industry base, hemp community, Xixiang street, Bao'an District, Shenzhen, Guangdong Province Patentee after: Tiangu information technology (Shenzhen) Co.,Ltd. Address before: 518100 3b06, building 3, area a, Bao'an Internet industry base, hemp community, Xixiang street, Bao'an District, Shenzhen, Guangdong Province Patentee before: SKYSOLIDISS INFORMATION SAFETY SYSTEM (SHENZHEN) Co.,Ltd. |
|
| CP01 | Change in the name or title of a patent holder | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230911 Address after: 518000 west of floor 5-3-west of floor 6, building 2, shunheda plant, liuxiandong Industrial Zone, Xinwei community, Xili street, Nanshan District, Shenzhen, Guangdong Patentee after: Tiangu information security system (Shenzhen) Co.,Ltd. Address before: 518100 3b06, building 3, area a, Bao'an Internet industry base, hemp community, Xixiang street, Bao'an District, Shenzhen, Guangdong Province Patentee before: Tiangu information technology (Shenzhen) Co.,Ltd. |
|
| TR01 | Transfer of patent right |