CN110532239B - File system management method, device, equipment and storage medium - Google Patents

File system management method, device, equipment and storage medium Download PDF

Info

Publication number
CN110532239B
CN110532239B CN201910849041.0A CN201910849041A CN110532239B CN 110532239 B CN110532239 B CN 110532239B CN 201910849041 A CN201910849041 A CN 201910849041A CN 110532239 B CN110532239 B CN 110532239B
Authority
CN
China
Prior art keywords
block
write operation
file system
operation information
version
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.)
Active
Application number
CN201910849041.0A
Other languages
Chinese (zh)
Other versions
CN110532239A (en
Inventor
张之浩
阮安邦
华仁杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Soochow Securities Co ltd
Beijing Octa Innovations Information Technology Co Ltd
Original Assignee
Soochow Securities Co ltd
Beijing Octa Innovations Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Soochow Securities Co ltd, Beijing Octa Innovations Information Technology Co Ltd filed Critical Soochow Securities Co ltd
Priority to CN201910849041.0A priority Critical patent/CN110532239B/en
Publication of CN110532239A publication Critical patent/CN110532239A/en
Application granted granted Critical
Publication of CN110532239B publication Critical patent/CN110532239B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/11File system administration, e.g. details of archiving or snapshots
    • G06F16/122File system administration, e.g. details of archiving or snapshots using management policies
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/172Caching, prefetching or hoarding of files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1873Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/188Virtual file systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention discloses a file system management method, a device, equipment and a storage medium, wherein the management method comprises the following steps: receiving write operation information, generating a transaction, and recording the write operation information into the transaction; writing the transaction into an unmounted block; mounting the non-mounted block to the end of the current block chain. According to the scheme of the invention, all the detailed information of the write operation of the file system is stored through the block chain, so that the file system has traceability, is easy to monitor and is safer.

Description

File system management method, device, equipment and storage medium
Technical Field
The invention belongs to the field of file storage, and particularly relates to a file system management method, a device, equipment and a storage medium.
Background
The distributed file system has good scalability and higher performance, and is a file system widely used at present. The distributed file system is generally used at the back end of a service system, provides file support for a Server (such as a Web Server) at the front end, and does not directly face a user, so that generally, only few security protection measures are provided. However, bugs and trapdoors exist inevitably in the distributed file system, and the possibility of hijacking still exists. Once some part of the system is hijacked, the information in it may be tampered with.
However, the existing distributed file system cannot trace the source of the file, and the supervision is difficult, so that a safer and easily-supervised distributed file system needs to be provided for the purpose.
Disclosure of Invention
The invention aims to provide a file system management method, a file system management device, a file system management equipment and a storage medium.
In order to achieve one of the above objects, an embodiment of the present invention provides a file system management method, including:
receiving write operation information, generating a transaction, and recording the write operation information into the transaction;
writing the transaction into an unmounted block;
mounting the non-mounted block to the end of the current block chain.
As a further improvement of an embodiment of the present invention, the "writing the transaction into an unmounted block" specifically includes:
when a block is generated based on the current blockchain, one or more transactions are written into a generated block.
As a further improvement of an embodiment of the present invention, the "mounting the unmounted block to the end of the block chain" specifically includes:
s31: and repeatedly trying to mount the unmounted block at the tail end of the current block chain until the mounting is successful or the current block chain is changed.
As a further improvement of an embodiment of the present invention, the method further comprises:
s32, when the un-mounted block is not mounted successfully and the current block chain is changed, the block is cancelled, the un-mounted block is generated based on the latest block chain, one or more transactions are written into a mounted block, and the steps S31-S32 are repeated.
As a further improvement of an embodiment of the present invention, when an unmounted block is successfully mounted, the block is connected to an end block of a current block chain to form a latest block chain, and all blocks of the latest block chain are traversed in sequence to generate a latest virtual file system.
As a further improvement of an embodiment of the present invention, the "traversing all blocks of the latest block chain in order to generate the latest virtual file system" specifically includes:
reading all write operation information recorded in each block one by one according to the sequence of the block numbers;
if the object of the write operation information is a certain file, recording a version number corresponding to the write operation information in a version set of the file;
and if the object of the write operation information is a folder, performing write operation on the current virtual file system according to the write operation information.
As a further improvement of an embodiment of the present invention, when a read operation on a certain file is received, a version set of the file is obtained from a current virtual file system;
and sequentially executing the write operation of the write operation information records corresponding to the version numbers according to the sequence of the version numbers in the version set, thereby generating the file.
As a further improvement of an embodiment of the present invention, the "recording the write operation information in the transaction" means writing the write operation information in an OP _ RETURN field of the transaction.
In order to achieve one of the above objects, an embodiment of the present invention provides an electronic device, including a memory and a processor, where the memory stores a computer program operable on the processor, and the processor implements the steps in any of the file system management methods when executing the program.
To achieve one of the above objects, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps in any of the file system management methods described above.
The invention has the advantages that:
the file system management method of the embodiment stores all the detailed information of the write operation of the file system through the blockchain, so that the file system has traceability, is easy to monitor and is safer.
Drawings
Fig. 1 is a functional block diagram of a file system management apparatus in a fourth embodiment of the present invention.
FIG. 2 is a network diagram of a network deployment of the distributed file system of the present invention.
Fig. 3 is a flowchart illustrating a file system management method according to a first embodiment of the present invention.
FIG. 4 is a block chain structure diagram of the distributed file system of the present invention.
Fig. 5 is a flowchart illustrating a file system management method according to a second embodiment of the present invention.
Fig. 6 is a flowchart illustrating a file system management method according to a third embodiment of the present invention.
Detailed Description
So that the manner in which the above recited objects, features and advantages of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings. It should be noted that the embodiments and features of the embodiments of the present application may be combined with each other without conflict.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, however, the present invention may be practiced in other ways than those specifically described herein, and therefore the scope of the present invention is not limited to the specific embodiments disclosed below.
As shown in fig. 1, according to an embodiment of the present invention, a system architecture of a distributed file system of the present invention includes an interface layer, a caching module, a processing module, and a storage module.
The interface layer is used for providing functions of a file system to the outside, files and folders in the file system can be regarded as a resource, and the interface layer can provide interfaces for the following operations to the outside: querying a resource (hereinafter referred to as a read operation), adding a resource, deleting a resource, modifying a resource, and the like (operations of adding, deleting, and modifying a resource are hereinafter collectively referred to as write operations). The interface layer can also provide an interface for inquiring virtual file systems of different versions externally.
The cache module is used for reading the write operation information stored in the block chain, and constructing a tree structure of the file system in the memory to form a typical file system structure view of the directory-file. And meanwhile, the read operation request issued by the interface layer is also received. Meanwhile, the cache module is also used for caching versions which are commonly used by a file system.
The processing module is used for converting the write operation request issued by the interface layer into a block.
The storage module stores all write operation information to the file system in the form of a block chain, and the subsequent storage module is also called a block chain.
As shown in fig. 2, according to an embodiment of the present invention, the distributed file system of the present invention may perform the following network deployment: the network comprises a plurality of nodes (the nodes can be a computer) which can communicate with each other, the nodes can all comprise an interface layer, a cache module, a processing module and a storage module of a file system, or only comprise partial modules of the file system, and all the nodes form a file management system based on the block chain technology. In addition, the file system may further include a client, where the client may be disposed on the node or may not be disposed on the node, and the client may access or modify the file system through an interface layer on a certain node.
The distributed file system of the present invention is implemented based on a block chain technology, and for facilitating understanding of the technical solution of the present invention, a structure of a block chain is introduced, where the block includes a block header and a block body.
Referring to table 1, the block header mainly includes three sets of data. First is a set of data that references the parent chunk hash value, which is used to connect the chunk with the previous chunk in the chain of chunks. The second set of data includes a difficulty target, a timestamp, and a random value for computing a valid hash value for the block. The third set of data, the Merkle root, is associated with a specific transaction in the block body.
Figure 67949DEST_PATH_IMAGE001
The block is used for recording the transaction amount and the transaction data stored in the block. Each transaction in the block may include an OP _ RETURN field that is used to carry additional transaction information, such as remark information during daily transfers. In the block chain-based distributed file system of the present invention, the write operation record of the file is stored mainly by using this field.
In addition, each block in the block chain has two identifiers for identifying the block, the first identifier is the hash value of the block, the block hash value can uniquely and definitely identify one block, and any node can independently acquire the block hash value by simply performing hash calculation on the block head. The second identifier identifies the location of the block in the block chain, i.e., "block height". The first block, which has a block height of 0. Thus, a chunk can be identified in two ways, either by a chunk hash value or a chunk height. Each tile subsequently stored on top of the first tile is "higher" in the tile chain by one position than the previous tile, as if the bins were stacked one on top of the other.
Example one
The present embodiment provides a file system management method, as shown in fig. 3, the method includes:
receiving write operation information, generating a transaction, and recording the write operation information into the transaction;
writing the transaction into an unmounted block;
mounting the non-mounted block to the end of the current block chain.
In the technical scheme of the invention, the OP _ RETURN field of the transaction is used for storing write operation information to the file system, namely when the write operation information is received, a transaction is generated, and the write operation information is recorded into the OP _ RETURN field of the transaction (so that the transaction number of the block is equal to the number of the write operation information of the block). The whole block chain can be seen as a linked list as shown in fig. 4, and the whole block chain includes N blocks, and each block includes X pieces of operation information (the number X of operation information included in each block is not fixed).
In this embodiment, when the interface layer of a node receives the write operation information, a transaction is generated, the write operation information is recorded in the transaction, and then the transaction is sent to the processing module corresponding to the node and broadcasted to the processing modules of other nodes.
The processing module writes the transactions recorded with the write operation information into the unmounted block and tries to mount the unmounted block to the end of the current block chain. The process specifically comprises the following steps:
each processing module records these unacknowledged transactions and, based on the current blockchain, generates blocks that include these unacknowledged transactions (the newly generated blocks include the hash value of the end block of the current blockchain, also called the parent hash value), and then each node that includes a processing module and a blockchain attempts to mount the newly generated blocks (or so-called the unaffiliated blocks) to the end of the current blockchain.
The specific process of mounting is to repeatedly modify a random variable in an unmounted block, calculate the hash value of the block until a valid hash value is calculated, after the valid hash value is calculated, the block is considered to be successfully mounted at the end of the current block chain, at this time, all the unconfirmed transactions included in the block are changed into confirmed transactions, and the successfully mounted block is broadcasted to other nodes. However, if the block has not been successfully mounted and the blocks generated at other nodes have been successfully mounted (i.e., the current chain of blocks has changed), the block is deactivated, a block including an unconfirmed transaction is regenerated based on the latest chain of blocks (an empty block is generated if an unconfirmed transaction does not currently exist), and the mounting process is repeated.
It should be noted that the write operation information of each transaction corresponds to a version number N-m of the file system, where N is a block number, and m is the mth transaction in the block N. Similarly, a version number of a file system corresponds to a transaction (or a piece of write operation information).
The file system management method of the embodiment stores all the detailed information of the write operation of the file system through the blockchain, so that the file system has traceability, is easy to monitor and is safer.
The specific definition of DATA OP _ RETURN _ DATA in OP _ RETURN can be seen in table 2, OP _ RETURN _ DATA: = BYTE ARG …, BYTE represents the operation type, the ARG may be a STRING, or may be a non-negative integer INT, or may be binary DATA. When BYTE is 1, the creation of the directory mkdir is indicated, and only a STRING STRING indicating the directory path needs to be followed. When BYTE is 3, this means that data is written to a specified location writefile of a specified file, followed by the file path STRING of this file, the start location INT of the written data, and the data of the written file.
Figure 934273DEST_PATH_IMAGE002
The above-mentioned write operation can be implemented by calling the existing system interface function, and the system function is as follows:
mkdir (dirpath): and creating a new directory.
deldir (dirpth): the directory is deleted.
writefile (filename, startpos, data): this interface is also used for new files, by writing data to the designated locations of the files.
resizefile (filepath, size): the file size is reset, the excess is deleted and the insufficient is filled with 0.
delfile (filename): and deleting the file. In addition, the block generation period of the block chain of the invention can be adjusted according to the network state of the technical scheme of the invention or the number of nodes deployed in the block chain, and the like, and typically 1 s-30 s can be selected to be different, so that the block growth speed is increased, and the operation performance of the system can be improved. Reducing the validation time for the transaction. When a write operation command is issued, the transaction for recording the write operation information corresponding to the command needs to wait for the transaction to be in a confirmed state, and then a reply can be received, wherein the reply has a version number.
Preferably, the file system management method of this embodiment further includes:
all transactions of all blocks of the current blockchain are traversed in sequence to generate a virtual file system. The specific way of generating the virtual file system may be: and reading the write operation information of the transaction record of each block from the first block of the block chain, and recording the sequence of the write operation information, and after the reading of all the blocks is finished, executing the write operation recorded in the write operation information to the initial file system according to the recorded sequence. The initial file system may be a blank file system or a file system with specific content. When the initial file system is not a blank file system, the contents of the initial file system may be recorded in a founder transaction of a founder block (first transaction of the first block).
Of course, the specific way of generating the virtual file system may also be: the write operation information recorded in the block is read from the first block of the block chain, and then the write operation recorded in the write operation information is executed to the initial file system. And then repeating the operations on the subsequent blocks of the block chain in sequence, wherein the repeated process is not to perform the write operation on the initial file system, but to perform the write operation on the file system generated by the last block.
It should be noted that, when performing a write operation on a file system, in order to save a storage space, when the write operation is directed to a folder, the corresponding write operation is performed on the file system; when the write operation is for a file, only the version number corresponding to the write operation needs to be recorded in the file system (i.e., if the write operation for the file is included in version 1-3, version 3-2, version M-X, then the version number 1-3, 3-2, and M-X corresponding to the file is recorded in the file system). It can be understood that, when a file is desired to be accessed, the data in the file can be obtained by obtaining the write operation recorded by the write operation information under the corresponding block number according to the number of the version corresponding to the file.
In order to ensure the validity of the write operation information recorded in the block chain, preferably, when the interface module receives the write operation information, the interface module sends the write operation information to the cache module to judge the validity of the write operation information, and if the write operation is legal, the interface module sends the write operation information to the processing module corresponding to the node.
Example two
The present embodiment provides a file system management method with version function, as shown in fig. 5, the method includes:
receiving a command for checking a virtual file system with the version number of N-m;
and traversing the current area chain from the first piece of write operation information of the first block in sequence until the mth operation record of the nth block is traversed, and generating the virtual file system with the version number of N-m.
The embodiment provides a file system management method with a version function, and the embodiment explains the version function of a file system in detail on the basis of the first embodiment. When a block is successfully mounted at the tail end of the block chain of the current version, the block is connected with the tail end block of the block chain of the current version to form a block chain of the latest version, the number of the successfully mounted block is N, and m transaction records are included in the block and respectively correspond to the version numbers N-1 to N-m of m file systems. That is, the write operation information of each transaction corresponds to a version number N-m of the file system, where N is the block number and m is the mth transaction in block N. Similarly, the version number also corresponds to a block number and a transaction number.
Preferably, "traversing the current area chain from the first write operation information of the first block in sequence until the mth operation record of the nth block is traversed, and generating the virtual file system with the version number of N-m" specifically includes:
and after the mth write operation information of the Nth block is read, executing the write operation recorded in the write operation information to the virtual file system of the initial version according to the recorded sequence to generate the virtual file system of the version N-m.
The initial file system may be a blank file system or a file system with specific content. When the initial file system is not a blank file system, the contents of the initial file system may be recorded in a create transaction of a create block (first transaction of a first block).
Of course, the "generating a virtual file system with a version number N-m" may also be: and executing the write operation recorded in the write operation information every time one or more pieces of write operation information are read from the first piece of write operation information of the first block to the mth piece of write operation information of the nth block of the block chain.
In addition, at query time, a query may be made for a specific version. When the interface layer of a node receives the read operation information, that is, the file system needs to be queried, the following interfaces may be invoked:
stat (path, version): and inquiring directory and file attributes.
lsdir (dirpath, version): listing the subdirectories and files in the directory. readfile (filepath, starpos, size, version): reading file content
The query is based on the version number, namely the relevant information of the corresponding version is obtained according to the version number, and if the version is null, the relevant information of the latest version is obtained. Because each block has a time stamp, namely the generation time of the block, when the file system is attacked at a certain time and the file is tampered, the version of the file system before the attack and the version after the attack can be compared to find out the tampered place, and the tampered place is reversely operated, so that the file system can be recovered to be normal.
The distributed file system management method with the version function provided by the embodiment enables the file system to have traceability, easy to monitor and safer.
EXAMPLE III
This embodiment provides a file system management method with version function, which is an optimization of the method of the second embodiment, as shown in fig. 6, and the method includes:
receiving a command for checking a virtual file system with the version number of N-m;
acquiring a cache version, wherein the version number of the cache version is X-Y, and the cache version is a version before an N-m version;
and traversing the current region chain from the next write operation information of the Y write operation information of the X block in sequence until the mth operation record of the Nth block is traversed, and generating a virtual file system with the version number of N-m on the basis of the cache version.
Since some versions may be more common, in order to increase the speed of the query, the common versions may be cached in the caching module. In this embodiment, a virtual file system with a version number of N-m is generated based on these cached versions. This can improve the efficiency of the query. Of course, the premise is that the cached version is the N-m previous version (previous version means that the cached version has a block number that is less than the block number of the N-m version, or the cached version is the same as the block number of the N-m version, but the transaction number is less than the transaction number of the N-m version).
Specifically, traversing the current region chain from the next write operation information of the Y write operation information of the X block in sequence until the mth operation record of the Nth block is traversed, and generating the virtual file system with the version number of N-m on the basis of the cache version X-Y. On the basis of the cache version X-Y, the next transaction of the Y transaction of the X block and the write operation contained in the write operation information recorded from the mth transaction of the Nth block are sequentially executed, and a virtual file system with the version number of N-m is generated.
For example, if the version of the cached file system is 5-7 (the 7 th write operation information of the fifth chunk), and the virtual file system of the latest version N-m needs to be generated, the operations of 5-8, 5-9 … N-1 and N-2 … N-m (the operation of N-m refers to the write operation recorded in the mth write operation information of the nth chunk) may be sequentially performed on the basis of the file system of 5-7.
In a preferred embodiment, the "obtaining a cached version" specifically includes:
finding a cache version before the plurality of N-m versions;
and selecting the cache version closest to the N-m version as the required cache version.
And when a plurality of cache versions which meet the requirements (before the N-m versions) exist, selecting the closest cache version as the required cache version. When the closest cache version is selected, the block numbers of the cache versions can be compared firstly, the cache version where the block number with the minimum difference with the N is located is selected, and if the cache version with the same block number exists, the transaction numbers can be compared.
For example, a virtual file system with a version number of 10-5 needs to be checked, the currently acquired cache versions are 2-8, 7-9 and 7-5, and the 7-9 version is selected as the closest cache version according to the method.
Example four
As shown in fig. 1, the present embodiment provides a management apparatus for a file system, which is applicable to the management methods in the first to third embodiments.
For clarity and conciseness of description, only one drawing is adopted in the present application, and the management device includes an interface layer 11, a cache module 13, a processing module 15 and a blockchain 17. Of course, modules that are not used in the corresponding management method can be removed from the management device.
Wherein, when the management apparatus corresponds to the management method of the first embodiment described above, the management apparatus includes:
a block chain 17 configured to store all write operation information in a form of a plurality of blocks connected;
an interface layer 11 configured to provide an interface for a write operation to the outside and convert the write operation into write operation information;
the processing module 15 is configured to record the write operation information into the transaction, generate one or more transaction blocks and mount the blocks at the tail end of the block chain;
the cache module 13 is configured to generate a virtual file system by traversing all the blocks of the block chain.
Preferably, the cache module 13 is further configured to:
reading the write operation information recorded by each block one by one according to the sequence of the block numbers;
if the object recorded by the write operation information is a certain file, recording the version number corresponding to the write operation information in a version set of the file;
and if the object of the write operation is a folder, executing the write operation.
Preferably, the cache module 13 is further configured to:
when receiving a read operation on a certain file, acquiring a version set of the file;
and sequentially executing the write operation recorded in the write operation information corresponding to the version number according to the sequence of the version numbers in the version set, thereby generating the file.
Preferably, the interface layer is further configured to send the write operation to the cache module when the write operation is received;
the cache module is further configured to determine whether the write operation is implementable.
Wherein, when the management apparatus corresponds to the management method of the second embodiment described above, the management apparatus includes:
the interface layer 11 is configured to externally provide an interface for viewing the virtual file system of the version N-m;
a block chain 17 configured to store all write operation information to the virtual file system in a form of a plurality of blocks being connected;
the cache module 13 is configured to traverse the current region chain from the first write operation information of the first block in sequence until the mth write operation information of the nth block is traversed, and generate a virtual file system of version N-m.
Preferably, the cache module 13 is further configured to:
reading the write operation information recorded by each block one by one from the first write operation information of the first block to the mth write operation information of the nth block in sequence;
and executing the write operation recorded in the write operation information on the virtual file system of the initial version to generate a virtual file system of the version N-m.
Wherein, when the management apparatus corresponds to the management method of the third embodiment described above, the management apparatus includes:
the interface layer 11 is configured to externally provide an interface for viewing the virtual file system of the version N-m;
a block chain 17 configured to store all write operation information to the virtual file system in a form of a plurality of blocks being connected;
the cache module 13 is configured to obtain a cache version, the version number of the cache version is X-Y, and the cache version is a version before the N-m version; and simultaneously traversing the current region chain from the next write operation information of the Y write operation information of the X block in sequence until the mth operation record of the Nth block is traversed, and generating a virtual file system with the version number of N-m on the basis of the cache version.
Preferably, the cache module 13 is further configured to:
finding a cache version before the plurality of N-m versions;
and selecting the cache version closest to the N-m version as the required cache version.
The invention further provides an electronic device, which includes a memory and a processor, where the memory stores a computer program operable on the processor, and the processor implements the steps in the file system management method according to the first embodiment or the second embodiment when executing the computer program.
The present invention further provides a computer-readable storage medium, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the file system management method according to embodiment one or embodiment two.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims (8)

1. A file system management method, the method comprising:
receiving write operation information, generating a transaction, and recording the write operation information into the transaction;
writing the transaction into an unmounted block;
mounting the unmounted block to the end of a current block chain;
when an unmounted block is mounted successfully, the block is connected with the tail end block of the current block chain to form a latest block chain, and all blocks of the latest block chain are traversed in sequence to generate a latest virtual file system;
reading all write operation information recorded in each block one by one according to the sequence of the block numbers;
if the object of the write operation information is a certain file, recording a version number corresponding to the write operation information in a version set of the file;
and if the object of the write operation information is a folder, performing write operation on the current virtual file system according to the write operation information.
2. The method according to claim 1, wherein said writing the transaction into an unmounted block comprises:
when a block is generated based on the current blockchain, one or more transactions are written into a generated block.
3. The file system management method according to claim 1, wherein said mounting the unmounted block to the end of the block chain comprises:
s31: and repeatedly trying to mount the unmounted block at the tail end of the current block chain until the mounting is successful or the current block chain is changed.
4. The file system management method according to claim 3, wherein said method further comprises:
s32, when the un-mounted block is not mounted successfully and the current block chain is changed, the block is cancelled, the un-mounted block is generated based on the latest block chain, one or more transactions are written into a mounted block, and the steps S31-S32 are repeated.
5. The file system management method according to claim 1, wherein:
when receiving a read operation on a certain file, acquiring a version set of the file from a current virtual file system;
and sequentially executing the write operation of the write operation information records corresponding to the version numbers according to the sequence of the version numbers in the version set, thereby generating the file.
6. The file system management method according to claim 1, wherein:
the "recording the write operation information into the transaction" means writing the write operation information into an OP _ RETURN field of the transaction.
7. An electronic device comprising a memory and a processor, said memory storing a computer program operable on said processor, wherein said processor implements the steps of the file system management method according to any of claims 1-6 when executing said program.
8. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the file system management method according to any one of claims 1 to 6.
CN201910849041.0A 2019-09-09 2019-09-09 File system management method, device, equipment and storage medium Active CN110532239B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910849041.0A CN110532239B (en) 2019-09-09 2019-09-09 File system management method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910849041.0A CN110532239B (en) 2019-09-09 2019-09-09 File system management method, device, equipment and storage medium

Publications (2)

Publication Number Publication Date
CN110532239A CN110532239A (en) 2019-12-03
CN110532239B true CN110532239B (en) 2022-05-06

Family

ID=68667837

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910849041.0A Active CN110532239B (en) 2019-09-09 2019-09-09 File system management method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN110532239B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101192204A (en) * 2006-11-28 2008-06-04 英业达股份有限公司 Data access method
CN109214823A (en) * 2018-08-27 2019-01-15 北京京东金融科技控股有限公司 Transaction verification method, device, storage medium and electronic equipment based on block chain
CN109426949A (en) * 2017-08-29 2019-03-05 华为技术有限公司 Across the chain method of commerce of one kind and device

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101192204A (en) * 2006-11-28 2008-06-04 英业达股份有限公司 Data access method
CN109426949A (en) * 2017-08-29 2019-03-05 华为技术有限公司 Across the chain method of commerce of one kind and device
CN109214823A (en) * 2018-08-27 2019-01-15 北京京东金融科技控股有限公司 Transaction verification method, device, storage medium and electronic equipment based on block chain

Also Published As

Publication number Publication date
CN110532239A (en) 2019-12-03

Similar Documents

Publication Publication Date Title
US20220414090A1 (en) Blockchain data index method, blockchain data storage method and device
CN104951474B (en) Method and device for acquiring MySQL binlog incremental log
US8214334B2 (en) Systems and methods for distributed system scanning
CN103036956B (en) A kind of distributed configuration mass data filing system and implementation method
CN110262922B (en) Erasure code updating method and system based on duplicate data log
CN113986873B (en) Method for processing, storing and sharing data modeling of mass Internet of things
US9367569B1 (en) Recovery of directory information
US20080140733A1 (en) I/O free recovery set determination
CN105550371A (en) Big data environment oriented metadata organization method and system
CN108021717B (en) Method for implementing lightweight embedded file system
Patil et al. GIGA+ scalable directories for shared file systems
US20070143286A1 (en) File management method in file system and metadata server therefor
Tang et al. Deferred lightweight indexing for log-structured key-value stores
CN102508913A (en) Cloud computing system with data cube storage index structure
CN104184812A (en) Multi-point data transmission method based on private cloud
CN106682139A (en) Method and system for achieving HBase multi-condition query based on Solr
CN110569221B (en) File system management method, device, equipment and storage medium with version function
US9934248B2 (en) Computer system and data management method
CN104516945A (en) Hadoop distributed file system metadata storage method based on relational data base
US20110302213A1 (en) Storage system
US8589652B2 (en) Reorganization of a fragmented directory of a storage data structure comprised of the fragmented directory and members
CN114116612A (en) B + tree index-based access method for archived files
US7668846B1 (en) Data reconstruction from shared update log
CN109032526A (en) data processing method and device for distributed file system
CN110532239B (en) File system management method, device, equipment and storage medium

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