CN1517906A - Document system and document management method - Google Patents
Document system and document management method Download PDFInfo
- Publication number
- CN1517906A CN1517906A CNA031003400A CN03100340A CN1517906A CN 1517906 A CN1517906 A CN 1517906A CN A031003400 A CNA031003400 A CN A031003400A CN 03100340 A CN03100340 A CN 03100340A CN 1517906 A CN1517906 A CN 1517906A
- Authority
- CN
- China
- Prior art keywords
- file
- data
- database
- actual
- file system
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A file system created on storage medium is composed of a data region for storing actual file data and a meta-data region for storing mark data used for mapping between physical data and logical data. It features that the unidirectional link table of the physical positions for the data of each actual file in the data region is stored in the meta-data region for managing the actual files according to the index address of each unidirectional link table. Its file managing method includes reading data from metal-data region to form a database file, and accessing the database file to get the index address of unidirectional link table for managing the actual files.
Description
Technical field
The present invention is about a kind of file system and file management method that is used for computer system.
Background technology
File system is to be structured on the Physical Extents of storage medium, in order to the store files data.File system is a kind of important channel of operating system access data, when one section code or routine access are kept at data on disk or other storage mediums, always corresponding operating system is submitted in request generally speaking, according to the characteristics of the specific file system of registering in the system request of access is navigated to corresponding physical location by operating system, visit corresponding actual physics data and these data are required to be assembled into logic data structure according to the characteristics of this document system at this physical location, the data of this moment are exactly available the data of certain sense to have been arranged for upper layer application.This shows the significance of efficient and rational file system for availability of data.
General file system is tree-shaped bibliographic structure, so-called " tree-shaped bibliographic structure " means that position that system file places is whole to seem the tree of turning around just as, " root directory " beginning by the superiors, under it file can be arranged, catalogue (being to be commonly called as it " file " in the microsoft system) also can be arranged, and sub-directory and file can also be arranged under each catalogue, one tunnel procreation like this forms the big tree that shape seemingly is thick with leaves.And each file just is referred to as " path (path) " in the position of this directory tree.The file configuration mode of this tree-shaped bibliographic structure is the big invention of UNIX, have a far reaching influence afterwards, there are many operating systems all to take such design, comprise current many outstanding file system under windows and these two kinds of modal computer operating systems of linux, such as the fat under the windows, fat32, ntfs, ext2 under the linux, ext3 are primarily aimed at the file system such as jfs, reseisfs that built-in field is used in addition.
But these file system generally speaking are a kind of general file system, mainly considered under most of general situations demand to file system, the institutional framework aspect of its data has many good qualities, but can not meet all demands, particularly in some specific application scenarios, such as comparatively special Embedded Application field.And these file system structures are more numerous and more jumbled, take more storage space, and access locating file speed is slow.
Summary of the invention
The problem to be solved in the present invention provides a file system simple in structure, can the quick access locating file and be suitable for specific application area.
For addressing the above problem, file system builds of the present invention is on storage medium, and its structure comprises the data field, the conservation zone of actual file data; Meta-data region, file system is set up the mapping relations from the physical data to the logical data and the conservation zone of the flag data used, it is characterized in that: meta-data region is preserved the single-track link table of the data storage physical location of each actual file in the data field, and make the data of each actual file have unique logical combination and preserve by database each single-track link table the physics conservation zone index address and actual file is managed.
Correspondingly, adopt the file management method of file system of the present invention may further comprise the steps:
1) reads the data of meta-data region 2, and related data is organized into database file;
2) utilize the database access database file to obtain the index address of single-track link table according to step 1);
3) to according to step 2) in the index address single-track link table that obtains existing actual file operate or set up new single-track link table, and then reach the management of actual file.
File system of the present invention and file management method have the following advantages:
File system of the present invention simple in structure also utilizes database effectively to improve the access efficiency of data.This cover file system both can be used under the built-in Linux environment, also can use under desktop Linux operating system/Windows environment, and for the occasion that particular requirement is arranged, can satisfy the requirements for access to data preferably.
Description of drawings
Fig. 1 is the structural representation of file system of the present invention.
Fig. 2 is the file partition synoptic diagram of file system of the present invention.
Fig. 3 is the synoptic diagram of the single-track link table among file system one embodiment of the present invention.
Fig. 4 is the single-track link table among Fig. 3 and the mapping relations synoptic diagram of data field data.
Fig. 5 is a file management method process flow diagram of the present invention.
Embodiment
Please refer to shown in Fig. 1,2, file system builds of the present invention is on storage medium 5, and the storage physical region of storage medium that file system is occupied is the file partition 1 of this document system.Storage medium 5 can be that hard disk also can be other storage mediums 51.File partition 1 can be subregion or a plurality of subregion or the DISK to Image of hard disk.
This document system partitioning 1 its structure is divided in logic 3 data zones according to the form of determining:
1) meta-data region 2, file system is set up the mapping relations from the physical data to the logical data and the conservation zone of the flag data used, promptly contains the zone of the flag data that the file system except the conservation zone of the data that authentic document comprised is used in order to set up the mapping relations from the physical data to the logical data in the file partition 1.This zone is visited by specific interface, and is not used in the data of preserving actual file;
2) data field 3, and DATA district 3 is built up in the conservation zone of actual file data; And
3) the meta-data region backup area 4, with the flag data in the backup meta-data region 2.
Wherein physical data is for preserving the amount of physical memory related data of actual file; Logical data then is the data that actual file comprised.
Meta-data region 2 is divided into 4 logical data zones again:
1) the file partition interblock 21, and the essential information of log file system is called for short PIT district 21;
2) file system has been distributed bunch recording areas 23, and the record actual file data is stored the single-track link table of physical location in data field 3, be called for short LAT district 23;
3) file system files record sheet recording areas 22, the index address of preservation actual file information and single-track link table is called for short FDB district 22; And
4) unallocated bunch of recording areas 24 of file system, the physical storage locations of recorded data zone is unallocated bunch representative is called for short LUT district 24.
The single-track link table that meta-data region 2 is preserved the data storage physical location of each actual file in data field 3 is the single-track link table in LAT district 23, and makes the data of each actual file have unique logical combination and be the index address in FDB district 22 and actual file is managed by the physics conservation zone that database is preserved each single-track link table.
Meta-data region backup area 4 correspondingly is divided into:
File system files record sheet recording areas backup area 41 is called for short FDB-BAK district 41;
File system has been distributed a bunch recording areas backup area 42, is called for short LAT-BAK district 42;
File system is a unallocated bunch recording areas backup area 43 is called for short LUT-BAK district 43; And
File partition interblock backup area 44 is called for short PIT-BAK district 44.
Meta-data region backup area 4 is kept at the last of file partition 1, rather than and then meta-data region 2 is preserved, in case when its benefit is that meta-data region 2 is subjected to physical hazard, reduce the possibility that this physical hazard damages meta-data region backup area 4 simultaneously as much as possible.Simultaneously, because the data integrity in PIT district 21 is extremely important to whole file system, the location definition in PIT-BAK district 44 is in last sector of whole file partition 1, this also be for carrying out safety backup PIT district 21 and when helping PIT district 21 and suffering damage to PIT-BAK district 44 design made with the purpose of recovering total system of location easily.
Describe each logical data zone of file partition below respectively in detail:
A) the file partition interblock 21, are called for short PIT district 21 data contents:
The data of preserving in this zone are the essential informations of the file partition 1 of file system, comprise the quantity of the reference position of each data area in the size, meta-data region 2 of reference position, the file partition of capacity, the file partition 1 of storage medium and size thereof, database file and reference position thereof, size.This zone is the basis of location each several part data in the file system, and is extremely important.Database file comprises: index file and data file, its composition and be based upon follow-up file management method and be described.
Operating system or upper level applications are by the visit of data that this zone is preserved, can obtain the essential information of file partition 1, and can demarcate the data area of variant meaning by these data, logically set up the structure of file partition 1, and the index file of location database and the information of data file are for searching and visit other zones and these data in regional have been set up the basis of addressing.
Data structure:
struct?st_effs_PIT{
∥ storage medium and subregion identification information
unsigned?int????ihdlength；
∥ hard disk (or other storage mediums) true capacity (is situated between to other storages with the sector
Matter is decided according to the concrete condition of storage medium) be unit;
unsigned?int????ieffsbegin；
∥ hard disk (or other storage mediums) file partition 1 reference position is with the sector
(other storage mediums are decided according to the concrete condition of storage medium) is unit;
unsigned?int????ieffslength；
∥ file partition 1 capacity (is situated between according to storage to other storage mediums with the sector
The concrete condition of matter and decide) for unit;
unsigned?int????iblocklength；
The size of 1 one physical store units of ∥ file partition is a unit with the byte;
unsigned?char?partname[16]；
The sign title of ∥ this document system partitioning 1;
unsigned?char?part-effs[4]；
∥ file partition 1 sign is necessary for word string " EFFS ";
The information in ∥ PIT district 21
unsigned?int????ieffsPITbegin；
The reference position of ∥ file partition interblock (PIT district) 21 is with the sector
(other storage mediums are decided according to the concrete condition of storage medium) is unit;
unsigned?int????ieffsPITlength；
The length of ∥ file partition interblock (PIT district) 21 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
The information in ∥ PIT-BAK district 44
unsigned?int????ieffsPIT-BAKbegin；
∥ file partition interblock backup area (PIT-BAK district) 44 start bits
Put, with sector (other storage mediums are decided according to the concrete condition of storage medium)
Be unit;
The information in ∥ FDB district 22
unsigned?int????ieffsFDBbegin；
The reference position of ∥ file system files record sheet recording areas (FDB district) 22 is with fan
District's (other storage mediums are decided according to the concrete condition of storage medium) is a unit;
unsigned?int????ieffsFDBlength；
The length of ∥ file system files record sheet recording areas (FDB district) 22 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
The information in ∥ FDB-BAK district 41
unsigned?int????ieffsFDB-BAKbegin；
Rising of ∥ file system files record sheet recording areas backup area (FDB-BAK district) 41
The beginning position, with the sector (to other storage mediums according to the concrete condition of storage medium and
Fixed) be unit;
The database index fileinfo in ∥ FDB district 22
unsigned?int????ifdbindexfilenum；
The number of the database index file in ∥ FDB district 22
unsigned?int????ifdbindexfilebegin；
The reference position of first index file of database in ∥ FDB district 22 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
unsigned?int????ifdbindexfilelength；
The length of first index file of database in ∥ FDB district 22, with the sector (to it
He decides according to the concrete condition of storage medium by storage medium) be unit;
unsigned?int????ifdbindexfilereserve；
∥ be after the upgrading of this structure keep;
The database datafile information in ∥ FDB district 22
unsigned?int????ifdbdatafilenum；
The number of the database datafile in ∥ FDB district 22
unsigned?int????ifdbdatafilebegin；
The reference position of first data file of database in ∥ FDB district 22 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
unsigned?int????ifdbdatafilelength；
The length of first data file of database in ∥ FDB district 22, with the sector (to it
He decides according to the concrete condition of storage medium by storage medium) be unit;
unsigned?int????ifdbdatafilereserve；
∥ be after the upgrading of this structure keep;
The information in ∥ LAT district 23
unsigned?int????ieffsLATbegin；
The ∥ file system has been distributed the reference position of a bunch recording areas (LAT district) 23, with the sector
(other storage mediums are decided according to the concrete condition of storage medium) is unit;
unsigned?int????ieffsLATlength；
The ∥ file system has been distributed the length of a bunch recording areas (LAT district) 23, and is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
The information in ∥ LAT-BAK district 42
unsigned?int????ieffsLAT-BAKbegin；
The ∥ file system has been distributed a bunch recording areas backup area (LAT-BAK district) 42 start bits
Put, with sector (other storage mediums are decided according to the concrete condition of storage medium)
Be unit;
The information in ∥ LUT district 24
unsigned?int????ieffsLUTbegin；
The reference position of a bunch recording areas that the ∥ file system is unallocated (LUT district) 24 is with fan
District's (other storage mediums are decided according to the concrete condition of storage medium) is a unit;
unsigned?int????ieffsLUTlength；
The length of a bunch recording areas that the ∥ file system is unallocated (LUT district) 24 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
The information in ∥ LUT-BAK district 43
unsigned?int????ieffsLUT-BAKbegin；
A bunch recording areas backup area (LUT-BAK district) 43 start bits that the ∥ file system is unallocated
Put, with sector (other storage mediums are decided according to the concrete condition of storage medium)
Be unit;
The database index fileinfo in ∥ LUT district 24
unsigned?int????ilutindexfilenum；
The number of the database index file in ∥ LUT district 24
unsigned?int????ilutindexfilebegin；
The reference position of first index file of database in ∥ LUT district 24 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
unsigned?int????ilutindexfilelength；
The length of first index file of T database in ∥ LUT district 24 is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
unsigned?int????ilutindexfilereserve；
∥ be after the upgrading of this structure keep;
The database datafile information in ∥ LUT district 24
unsigned?int????ilutdatafilenum；
The number of ∥ LUT district 24 database datafiles
unsigned?int????ilutdatafilebegin；
The reference position of ∥ LUT district 24 first data files of database is (right with the sector
Other storage mediums are decided according to the concrete condition of storage medium) be unit;
unsigned?int????ilutdatafilelength；
The length of ∥ LUT district 24 first data files of database, with the sector (to other
Storage medium is decided according to the concrete condition of storage medium) be unit;
unsigned?int????ilutdatafilereserve；
∥ be after the upgrading of this structure keep;
The information of ∥ data field 3
unsigned?int????ieffsDATAbegin；
∥ file system actual file data memory block is rising of data field (DATA district) 3
The beginning position, with the sector (to other storage mediums according to the concrete condition of storage medium and
Fixed) be unit;
unsigned?int????ieffsDATAlength；
∥ file system files data storage area is the length of data field (DATA district) 3,
With sector (other storage mediums are decided according to the concrete condition of storage medium) is list
The position;
The ∥ CRC check and
unsigned?int????ieffsCRC；
The redundant cyclic check of the data CRC in above 36 territories of ∥ and; ∥ end the defnition of structst_effs_PIT
The database index file information data item in the FDB/LUT district 22/24 in this data structure and database datafile information data item are the database file information in FDB/LUT district 22/24 in the file system, every group comprises 8 data item, be respectively the number (ifdb/lutindexfilenum) of database index file, the reference position of first index file of database (ifdb/lutindexfilebegin), the length of first index file of database (ifdb/lutindexfilelength), database index file reserved field (ifdb/lutindexfilereserve), the number of database datafile (ifdb/lutdatafilenum), the reference position of first data file of database (ifdb/lutdatafilebegin), the length of first data file of database (ifdb/lutdatafilelength), database datafile reserved field (ifdb/lutdatafilereserve), so design is based on following consideration: the database in the present embodiment adopts the SharkBase embedded database of association's software center exploitation, because this database satisfies following requirement, requirement also can be used below other databases satisfied in brief:
1) the SharkBase embedded type database system saves as data file to the data of forming relational data areas when handling, and the index data that database inside list is set up is saved as index file, sets up corresponding data dictionary and journal file simultaneously;
2) the modularization characteristics of SharkBase embedded database can realize the customization of function, because the applied environment of file system of the present invention does not need daily record, function such as synchronous, so in the SharkBase embedded database, remove the dependence of customer data base to data dictionary and journal file, like this, customer data base only depends on index file and data file;
3) for the identical data of content, above-mentioned data file and index file quantity are not clearly stipulated, the fabric and the core algorithm of this and database are closely related, such as, for the data content that has only a list, when in being limited to list, only setting up an index (promptly only a data field being set up index), optimize effect according to data volume and database core processing optimized Algorithm, might be that an index file adds a data file, also may be that a plurality of index files add a data file, also may be that an index file is added a data file, also may be that a plurality of index files are added a data file;
4) under similar Embedded applied environment, data volume is huge unlike desktop application, so under the situation of small data quantity, the SharkBase embedded database can guarantee that the quantity of data file and index file is one, and this provides convenience to location and read data files and index file in the FDB/LUT district 22/24.Consider the upgrading of version, in the st_effs_PIT structure, still defined ifdbdatafilereserve/ilutdatafilereserve data field and ifdbindexfilereserve/ilutindexfilereserve data field, used with multidata file after being preserved for and many index files.
5) can change along with the distribution condition of number of files in the file system and physical memory cell owing to data file and index file, so in FDB/LUT district 22/24, may maximum occupation space do restriction to index file and data file
Index file and data file occupation space ratio are 1: 3 in the FDB/LUT district 22/24, and index file is preceding, that is: hypothesis has FDB district 22 sizes of a file partition 1 to be 10M, then the index file maximum takies preceding 2.5M, data file is offset 2.5M and begins later on again from the FDB district, maximum takies 7.5M.
According to above description, database index file information data item and database datafile information data item have been designed among the structure st_effs_PIT.
In the above data structure when storage medium is hard disk, this PIT district 21 will take a sector to preserve data, but when storage medium is not hard disk, decide this zone should take much spaces according to the division principle of the storage cell of concrete storage medium when preserving data and preserve data, such as, when storage medium is flash, the size of supposing its piece that at every turn reads and writes data is 1K, then this zone should take data block preservation data of 1K size, and the unit of each data area in the data structure also is K.
B) file system files record sheet recording areas 22 is called for short FDB district 22
Data content:
This zone is the zone of preserving the index address information such as (i.e. the index addresses of this actual file single-track link table) of fileinfo and actual file shared physics conservation zone in file partition 1 in the file system, data in this zone are formed data of database file and index file, and wherein the data field of data file is referring to table 1.Database engine is read the data of database file, and being organized as fileinfo record sheet in the database, each data field in every table writes down file name, absolute path, file size, the creation-time of file, the last access time of file, the last modification time of file, the owner of file, the access rights of file and the index address of this actual file single-track link table of corresponding actual file.
The information of its data file and index file is used the number (ifdbindexfilenum) of database index file respectively in PIT district 21, the reference position of first index file of database (ifdbindexfilebegin), the length of first index file of database (ifdbindexfilelength), database index file reserved field (ifdbindexfilereserve), the number of database datafile (ifdbdatafilenum), the reference position of first data file of database (ifdbdatafilebegin), the length of first data file of database (ifdbdatafilelength), database datafile reserved field (ifdbdatafilereserve) is represented.
If under the windows desktop environment, use file system of the present invention, when then database is wanted the visit data library file, the interface that file system provides can with in the alternative document system under the windows desktop environment of copying in the FDB district 22 for database access, because database is by file access, it can't be skipped file system and directly visit physical memory cell, because this document system is not the file system at the exploitation of windows desktop environment, so the use to file system under the windows desktop environment must be a kind of use of specific use, certainly exists the file partition of other type that is complementary with the windows desktop environment in such cases.
If use this document system under the embedded Linux environment, file system can be beneficial to database access with index file in the FDB district 22 and data file copies in the ramfs memory file system of embedded Linux foundation.
| The database fields title | Absolute path (absolute path of file in file system comprises file name ,≤256 characters) | File size (is unit with the byte) |
| Database fields length | 256 bytes | 4 bytes |
| The database fields type | unsigned?char[256] | unsigned?int |
| The creation-time of file (xxxx-xx-xx-xx-xx-xx) year-moon-Ri-time-minute-second | (xxxx-xx-xx-xx-xx-xx) year-moon-Ri-time last access time of file-minute-second | The last modification time of file (xxxx-xx-xx-xx-xx-xx) year-moon-Ri-time-minute-second | The owner of file≤100 characters |
| 14 bytes | 14 bytes | 14 | 100 bytes |
| unsigned?char[14] | unsigned?char[14] | unsigned?char[14] | unsigned char[100] |
| The access rights of file | Local storage first address allocation index (Logic Cluster serial number) | Keep |
| 2 bytes | 4 bytes | 616 bytes |
| ????short | ????unsigned?int | ??unsigned?char[616] |
The owner of file: the founder who refers to file
The access rights of file: 0～2bit position of low byte order is represented file owner's reading and writing respectively, is carried out reading and writing, the execution authority of representing the group that the file owner is affiliated respectively in authority low byte 3～5bit position in proper order
6～8bit position of low byte order is represented reading and writing, the execution authority of other groups respectively
9～15bit position of low byte order keeps
Local storage first address allocation index (Logic Cluster serial number): record refers to that this actual file has distributed the address (index address) of first index block of single-track link table in bunch recording areas 23 in file system.
The territory of the data-base recording table of table 1 file system files record sheet recording areas 22
C) file system has been distributed bunch recording areas 23, is called for short LAT district 23
Data content:
This zone is the concordance list in whole file system actual file data district (DATA district) 3, and the concordance list of each actual file is a single-track link table.Represent a physical store unit (also can be described as storage unit) in the DATA district 3 with per 4 bytes in this zone, the size of a physical store unit is represented by the iblocklength data field in the PIT district 21, at storage medium is under the situation of hard disk, the size of a physical store unit can be 512 bytes, 1K byte, 4K byte, be (as flash) under the situation of other medium at storage medium, the size of a physical store unit is decided according to the situation of concrete medium and is recorded in the iblocklength data field in the PIT district 21.
Please refer to shown in Figure 3, each actual file has write down a corresponding index address in this locality storage first address allocation index territory in FDB district 22, this index address is first index block of this actual file of expression one 4 byte-sized of first physical storage locations in DATA district 3 in the LAT district 23, the data that this first index block is preserved are to represent the address of second index block of second physical storage locations of this actual file in the LAT district 23, second index block is preserved the address of the 3rd index block of representing the 3rd physical storage locations of this actual file in the LAT district 23 again, by that analogy, set up a unidirectional tabulation of forming in regular turn by one or more index blocks.Herein, physical storage locations is the address of storage unit, and promptly each index block is represented the address of the storage unit of this actual file data.
The index address of each single-track link table is the address of first index block of this single-track link table; And the many single-track link tables that index block constitutes.This single-track link table has been pointed out this document all physical storage locations in DATA district 3, and the content that last node of chained list is preserved is 0, always is not used in and distributes to actual file and be numbered 0 index block.The storage allocation situation of a certain actual file of expression that can be unique in file system so just, and the data that make this actual file have unique logical combination, the data of the physical storage locations in the DATA district 3 by reading the representative of this single-track link table just can realize the visit to this actual file.
Data structure:
struct?st_effs_LAT{
unsigned?int????ieffsLATlocal；
This index block of ∥ index number;
unsigned?int????ieffsLATnext；
The next index block index number of ∥;
struct?st_effs_LAT*??sLAT?next；
The head pointer of ∥ chained list next node;
}?∥end?the?definition?of?structst_effs_LAT
Please shown in Figure 4 in conjunction with reference, LAT district 23 data and DATA district 3 data map of a certain file concern synoptic diagram.
When system request is visited a certain actual file, system submits the filename of this actual file and the path at file place to database, the index address of this actual file in file system searched and obtained to database root according to these information, according to this index address, file system has been distributed a bunch recording areas (LAT district) 23 in can the access file system, set up the single-track link table that this actual file takies physical location according to the data in the LAT district 23, the data that physical location in the file system that this single-track link table is represented is stored are exactly the actual content of this actual file, it is exactly this document that the data combination that these physical locations are stored is got up, and can obtain the file size of this actual file simultaneously by database, the creation-time of file, the last access time of file, the last modification time of file, the owner of file, data such as the access rights of file.
D) unallocated bunch of recording areas 24 of file system is called for short LUT district 24
Data content:
This zone is the zone of the physical storage locations of unallocated bunch of representative of recorded data zone, database engine is read the data in the database file, and unallocated storage unit set up unallocated bunch of numbering, be organized as unallocated bunch of record sheet in the database, and write down the physical storage locations of unallocated bunch of representative.
The access method of this regional database is identical with database accessing method and principle in principle and the FDB district 22.The information of its data file and index file has been done definition in PIT district 21, use the number (ilutindexfilenum) of database index file respectively, the reference position of first index file of database (ilutindexfilebegin), the length of first index file of database (ilutindexfilelength), database index file reserved field (ilutindexfilereserve), the number of database datafile (ilutdatafilenum), the reference position of first data file of database (ilutdatafilebegin), the length of first data file of database (ilutdatafilelength), database datafile reserved field (ilutdatafilereserve) is represented.
When system request provides the storage space of physical storage locations representative for a new file, adopt the presents system may further comprise the steps:
D1) obtain not to be assigned with the total volume of amount of physical memory, this is to be obtained by the size (being represented by the iblocklength data field in the PIT district 21) that the summary journal bar number in this database file record multiply by each physical memory cell;
D2) relatively to add the size with the total volume of available amount of physical memory of taking up room of file;
D3) if less than the total volume of available amount of physical memory, then utilize record in this record sheet to obtain being assigned with bunch, whenever use up one and write down represented amount of physical memory, just this record of deletion in this table;
D4) distributed in bunch recording areas in file system simultaneously, set up the single-track link table of this interpolation file, and its real data has been write fully in the corresponding physical memory cell;
D5) in file system files record sheet recording areas, add the relevant fileinfo of file and the index address of single-track link table for this.
When file of system request deletion, adopt the presents system, may further comprise the steps:
D1) index address in the database file finds the single-track link table of this actual file in the data base manipulation;
D2) according to the address of the physical memory cell of each the index block representative in this single-track link table in unallocated bunch of record sheet of database, for corresponding each physical memory cell is set up unallocated bunch of numbering;
D3) delete the record of the fileinfo record sheet of this actual file, reach deletion and be kept at this actual file in the file system.The territory of the database table of a bunch recording areas that file system is unallocated (LUT district) 24 is as shown in table 2:
| The database fields title | Unallocated bunch of numbering | Unallocated bunch of actual sequence number |
| Database fields length | 4 bytes | 4 bytes |
| The database fields type | ??unsigned?int | ??unsigned?int |
Unallocated bunch of numbering: the record number in the database table
Unallocated bunch of actual sequence number: unallocated bunch of shared thing in the file system
The index address of reason conservation zone
The territory of the database table of unallocated bunch of recording areas of table 2 EFFS file system (LUT district) 24
E) DATA district 3 is called for short in the data field 3 of file system actual file
This zone is a physical storage area of preserving the file real data, the physical memory cell that has been assigned with in this zone belongs to different actual files according to it and logically forms a rule single-track link table in LAT district 23, the physical memory cell that is not assigned with in this zone in LUT district 24 by the data-base recording table institute index of a rule.
F) file system files record sheet recording areas backup area 41, are called for short FDBBAK district 41
This zone is a backup in FDB district 22, preserve the total data in the FDB district, its size is the same with FDB district 22 with content, when causing FDB district 22 to suffer damage owing to accident (as improper outage etc.) can't normally reading wherein data, and available data replacement in should the zone.After data in FDB district 22 are updated, all tackle this regional data and do synchronously, is the backup of complete FDB district 22 data to guarantee this zone all the time.
G) data in LAT-BAK district 42, LUT-BAK district 43, PIT-BAK district 44 and function and FDB-BAK district 41 are similar, and only Bei Fen object is respectively LAT district 23, LUT district 24, PIT-BAK district 21, repeats no more.
Just can set up file system according to each above-mentioned regional format and content.What should note when setting up file system a bit is: should pre-determine in this scheme zone divided maximum demand and preserve what files.This is because the entry number in the index dependency database FDB district 22 of file, and each the bar record in FDB district 22 record sheets takies the space of 1K, if fully dynamically set up this document system, in the worst case, the FDB district big young pathbreaker of 22 database occupation space who sets up is more than the twice in DATA district 3, to set up file system in the fdisk that is 512 bytes a smallest physical storage unit is example, that is:
Suppose that 3 spaces, DATA district size is xM, then DATA district 3 has x*1024*1024/512=2048x physical memory cells, if in the worst case, each storage unit is all represented a file, and the actual preservation length of every record of database all reaches maximum 1K, then the data-base recording bar number in the FDB district 22 is 2048x, the size of the database datafile among the FDB is at least 2048x*1K=2xM at this moment, add the index file occupation space, always taking up room to be more than the twice in DATA district 3, and this can cause bigger space waste.
So this document system recommendation user estimates the maximum number of files that needs preservation when the formatted file system.
In sum, be the structure and the principles illustrated of file system of the present invention, the specific implementation of file system of the present invention is described below.
In a PC, in order to realize to the carrying out safety backup of vital document and recovery and purpose that the file that has backed up is managed, hang a less hard disk in addition, capacity is 1.2G, an Embedded linux system is installed on this small harddisk, and mark off size and be used for the file on the big hard disk is backed up for the subregion of 1G (1024*1024=1048576K), this subregion is formatted as file partition 1 of the present invention.Two cover operating systems are arranged on the machine this moment: the windows2000 on the big hard disk, the embedded Linux on the small harddisk is all installed the SharkBase embedded database in these two systems.Then:
DATA district 3 sizes: 192* (1024*1024-26669)/203 ≈ 966532K;
PIT district 21 sizes: 512 bytes=0.5K;
FDB district 22 sizes: 10000*1K*4/3 ≈ 13334K;
LUT district 24 sizes: d/48 ≈ 20137K
Suppose that the starting position of this document system partitioning 1 on small harddisk is x sector, then each region parameter is as follows:
PIT district 21 reference positions are the x+0 sector, and length is 1 sector;
FDB district 22 reference positions are the x+1 sector, and length is 26668 sectors
LUT district 24 reference positions are the x+41773 sector, and length is 40274 sectors;
DATA district 3 reference positions are the x+82047 sector, and length is 1933064 sectors;
FDB-BAK district 41 reference positions are the x+2015111 sector, and length is 26668 sectors;
LAT-BAK district 42 reference positions are the x+2041779 sector, and length is 15104 sectors;
LUT-BAK district 43 reference positions are the x+2056883 sector, and length is 40274 sectors;
PIT-BAK district 44 reference positions are the ieffsbegin+ieffslength-1 sector, and length is 1 sector (i.e. last sector in this EFFS subregion);
This document system partitioning 1 reference position of record in the ieffsbegin:PIT district 21;
So just on this block space, set up file system of the present invention.The use of this document system can either be used in the windows operating system under this set of environments, also can use in the embedded Linux operating system under this set of environments.
Please refer to shown in Figure 5ly, adopt file system of the present invention and the method for carrying out file management, may further comprise the steps:
1) execution in step 61, read the data of meta-data region 2, and related data is organized into database file;
I. read the data of file partition interblock 21, obtain the file system essential information;
Ii. read the data of file system files record sheet recording areas 22, obtain the index address of basic document information and single-track link table, and be organized into corresponding data library file and preservation;
Iii. read the data of unallocated bunch of recording areas 24 of file system, obtain the physical storage locations relevant information of the 3 unallocated bunches of representatives in data field, and be organized into corresponding data library file and preservation;
2) execution in step 62, obtain the unallocated storage space total volume of this document system from step 61, and utilize the database access database file to obtain the index address of single-track link table;
3) execution in step 63, according to step 62) in index address obtain the single-track link table of existing actual file and be not assigned with the total volume of amount of physical memory, new single-track link table is operated or set up to single-track link table to existing actual file, and then reach the management of actual file;
4) execution in step 64, use the database update database file;
5) execution in step 65, synchronously the data of updating file system metadata district 2 respective data area;
6) the synchronous data of update metadata district backup area 4 respective data area;
Step I)-iii), call the interface that file system provides, read the data in the PIT district 21 in the partitions of file 1, FDB district 22 and LUT district 24 on the small harddisk, and the data extract in FDB district 22 and LUT district 24 come out, the data that utilization extracts are set up four data library file: fdb.dat, fdb.idx, lut.dat, lut.idx, are respectively FDB district 22 and LUT district 24 data files and index file.The data base manipulation database file is finished file management: visit, modification, interpolation, deletion, recovery etc.Wherein visit, the operation of interpolation, deleted file partly is described in the principle of file system of the present invention, and file modification and file access class of operation are seemingly, repeat no more.
When the actual file that will recover to back up in the past, the operation that its file recovers may further comprise the steps:
1) database finds this actual file index address in the FDB database file;
2) the single-track link table structure of the used storage unit engaged position in file partition 1 of this actual file that provides according to LAT district 23 in the file system;
3) in order the storage unit one by one of this actual file in the file partition 1 is copied to appointed place under the windows system according to this single-track link table structure, just finished the recovery of this document.
In addition, step 5), 6), need often the data of data library file and meta-data region 2 to be done to upgrade synchronously, to guarantee the consistance of database file content.
In addition, under the embedded Linux environment, can realize above-mentioned interpolation, deletion and reproduction process, only fdb.dat, fdb.idx, these four files of lut.dat, lut.idx are based upon among the ramfs file according to same step.
Under the linux environment, file partition 1 is formatted promptly to can be used as one later and can store with the file system of logical organization file and use, when SharkBase embedded database accessing database data file and database index file, the file system interface that calls can copy the content of the data of preserving in FDB district 22 and the LUT district 24 to ramfs by the data message in the PIT district 21, and is established as four data library files: FDB district 22 data files, FDB district 22 index files, LUT district 24 data files, LUT district 24 index files.Database can be realized visit to the actual file in the file system by visiting these several database files.Database will be updated to corresponding data area in the file partition 1 by the interface of file system to the modification of these several database files.
Under the windows desktop environment, realize this document system if use the SharkBase embedded database, then principle is same as described above, and unique difference is that database datafile and database index file will be created in the visible partition under the windows system this moment; If use the small sized personal database access under the windows to realize this document system, then be: in such cases with the difference that uses the SharkBase embedded database, because access has only a data library file, the item tax about data directory that needs only when file system builds like this data structure in the PIT district 21 is 0.
In sum, file system of the present invention is a dapper file system, and the operation of corresponding document management method is simple fast.
Claims (27)
1. a file system is structured on the storage medium, and its structure comprises the data field, the conservation zone of actual file data; Meta-data region, file system is set up the mapping relations from the physical data to the logical data and the conservation zone of the flag data used, it is characterized in that: meta-data region is preserved the single-track link table of the data storage physical location of each actual file in the data field, and make the data of each actual file have unique logical combination and preserve by database each single-track link table the physics conservation zone index address and actual file is managed.
2. file system as claimed in claim 1 is characterized in that: the storage physical region of storage medium that file system is occupied is the file partition of this document system.
3. file system as claimed in claim 2 is characterized in that, file partition is subregion or a plurality of subregion or the DISK to Image of hard disk.
4. file system as claimed in claim 2 is characterized in that, meta-data region is divided into 4 logical data areas:
The file partition interblock, the essential information of log file system;
File system has been distributed a bunch recording areas, the record single-track link table;
File system files record sheet recording areas, the index address of preservation actual file information and single-track link table;
A bunch recording areas that file system is unallocated, the physical storage locations of recorded data zone is unallocated bunch representative.
5. file system as claimed in claim 4 is characterized in that: each single-track link table is made of in regular turn one or more index blocks, and index address is the address of representative actual file at first index block of first physical storage locations of data field; First index block is preserved and is represented the address of actual file at second index block of second physical storage locations of data field; Second index block preserved and represented the address of actual file at the 3rd index block of the 3rd physical storage locations of data field; Become single-track link table by that analogy.
6. file system as claimed in claim 4 is characterized in that: the essential information of file system comprises the quantity of the reference position of each logical partition in the size, meta-data region of reference position, the file partition of the capacity of storage medium, file partition and size thereof, database file and reference position thereof, size.
7. file system as claimed in claim 4 is characterized in that: fileinfo comprises the file name, absolute path, file size, the creation-time of file, the last access time of file, the last modification time of file, the owner of file, the access rights of file of each actual file.
8. file system as claimed in claim 4, it is characterized in that: this document system also comprises the meta-data region backup area, with the corresponding flag data of backup meta-data region, corresponding file partition interblock, file system files record sheet recording areas, the file system of comprising distributed the backup area of bunch recording areas and unallocated bunch of recording areas of file system.
9. file system as claimed in claim 8, it is characterized in that: putting in order in the file partition is followed successively by meta-data region, data field and meta-data region backup area, and wherein file partition interblock backup area is placed on the final area of file partition.
10. a file management method is characterized in that this method comprises the steps:
1) reads the data of meta-data region, and related data is organized into database file;
2) utilize the database access database file to obtain the index address of single-track link table according to step 1);
3) to according to step 2) in the index address single-track link table that obtains existing actual file operate or set up new single-track link table, and then reach the management of actual file.
11. file management method as claimed in claim 10 is characterized in that: the file system metadata zoning is divided into a plurality of logical data areas:
The file partition interblock, the essential information of log file system;
File system has been distributed a bunch recording areas, and the record actual file data is stored the single-track link table of physical location in the data field;
File system files record sheet recording areas, the index address of preservation actual file information and single-track link table;
A bunch recording areas that file system is unallocated, the physical storage locations of recorded data zone is unallocated bunch representative.
12. file management method as claimed in claim 11 is characterized in that: step 1) further comprises the steps
A) read the data of file partition interblock, obtain the file system essential information;
B) read the data of file system files record sheet recording areas, obtain the index address of basic document information and single-track link table, and be organized into the corresponding data library file and preserve;
C) read the data of unallocated bunch of recording areas of file system, obtain the physical storage locations relevant information of the unallocated bunch of representative in data field, and be organized into the corresponding data library file and preserve.
13. file management method as claimed in claim 12 is characterized in that: the essential information of file system comprises the quantity of the reference position of each logical partition in the size, meta-data region of reference position, the file partition of the capacity of storage medium, file partition and size thereof, database file and reference position thereof, size.
14. file management method as claimed in claim 13 is characterized in that: fileinfo comprises the file name, absolute path, file size, the creation-time of file, the last access time of file, the last modification time of file, the owner of file, the access rights of file of each actual file.
15. file management method as claimed in claim 14 is characterized in that: the single-track link table of each actual file is made of in regular turn one or more index blocks, and each index block is represented the address of the storage unit of this actual file data.
16. file management method as claimed in claim 15 is characterized in that: the index address of each single-track link table is the address of first index block of this single-track link table; And first index block is preserved the address of second index block; Construction single-track link table by that analogy.
17. file management method as claimed in claim 16, it is characterized in that: database is read the data of the database file in the step b), and being organized as fileinfo record sheet in the database, each data field in every table writes down file name, absolute path, file size, the creation-time of file, the last access time of file, the last modification time of file, the owner of file, the access rights of file and the index address of this actual file single-track link table of corresponding actual file.
18. file management method as claimed in claim 17, it is characterized in that: database engine is read the data in the database file in the step c), and unallocated storage unit set up unallocated bunch of numbering, be organized as unallocated bunch of record sheet in the database, and write down the physical storage locations of unallocated bunch of representative.
19. file management method as claimed in claim 18 is characterized in that: the actual file management comprises interpolation, recovery, delete file operation.
20. file management method as claimed in claim 19 is characterized in that: add file operation and comprise the steps
Be not assigned with the total volume of amount of physical memory according to the information acquisition in the step a);
Relatively to add the size with the total volume of available amount of physical memory of taking up room of file;
If less than the total volume of available amount of physical memory, then utilize record in this record sheet to obtain being assigned with bunch, whenever use up one and write down represented amount of physical memory, just this record of deletion in this table;
Distributed in bunch recording areas in file system simultaneously, set up the single-track link table of this interpolation file, and its real data has been write fully in the corresponding physical memory cell;
In file system files record sheet recording areas, add the relevant fileinfo of file and the index address of single-track link table for this.
21. file management method as claimed in claim 19 is characterized in that: delete file operation comprises the steps
Index address in the data base manipulation step b) in the database file finds the single-track link table of this actual file;
According to the address of the physical memory cell of each the index block representative in this single-track link table in unallocated bunch of record sheet of database, for corresponding each physical memory cell is set up unallocated bunch of numbering;
Delete the record of the fileinfo record sheet of this actual file, reach and delete this actual file that is kept in the file system.
22. file management method as claimed in claim 19 is characterized in that: the operation of recovery file may further comprise the steps
Database finds this actual file index address in the FDB database file;
The single-track link table structure of storage unit engaged position in file partition 1 that this actual file that provides according to LAT district 23 in the file system is used;
In order the storage unit one by one of this actual file in the file partition 1 is copied to appointed place under the windows system according to this single-track link table structure, just finished the recovery of this document.
23. file management method as claimed in claim 10 is characterized in that: database file comprises that index file and data file storage space occupy ratio and be less than or equal to 1: 3.
24. file management method as claimed in claim 12, it is characterized in that: reading of data is to obtain by operating system or upper layer application accesses meta-data district that the user uses in step a)-step c), and temporarily database file is saved in the memory file system of employed operating system.
25. file management method as claimed in claim 24 is characterized in that: this database is an embedded database
26. file management method as claimed in claim 10 is characterized in that: document manipulation completing steps 3), use the database update database file simultaneously, and then the data of synchronous updating file system metadata district respective data area.
27. file management method as claimed in claim 26 is characterized in that: the data of synchronous update metadata district backup area respective data area during updating file system metadata district.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031003400A CN100504854C (en) | 2003-01-14 | 2003-01-14 | Document management method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031003400A CN100504854C (en) | 2003-01-14 | 2003-01-14 | Document management method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1517906A true CN1517906A (en) | 2004-08-04 |
| CN100504854C CN100504854C (en) | 2009-06-24 |
Family
ID=34281133
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB031003400A Expired - Fee Related CN100504854C (en) | 2003-01-14 | 2003-01-14 | Document management method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100504854C (en) |
Cited By (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006133597A1 (en) * | 2005-06-15 | 2006-12-21 | Intel Corporation | Using transacted writes and caching mechanism to improve write performance in multi-level cell flash memoty |
| CN100347705C (en) * | 2004-12-24 | 2007-11-07 | 北京中星微电子有限公司 | Method for file merge |
| CN100375093C (en) * | 2005-03-18 | 2008-03-12 | 联想(北京)有限公司 | Processing of multiroute processing element data |
| CN100444166C (en) * | 2005-12-16 | 2008-12-17 | 北京中星微电子有限公司 | Position-based interface access method and device for FAT file system |
| CN100557611C (en) * | 2007-11-15 | 2009-11-04 | 深圳华为通信技术有限公司 | A kind of disposal route of file and device |
| CN101692252A (en) * | 2009-08-31 | 2010-04-07 | 上海宝信软件股份有限公司 | Method for distributing and reclaiming idle blocks of file |
| CN101789027A (en) * | 2010-03-15 | 2010-07-28 | 江苏大学 | Metadata management method based on DBMS and metadata server |
| CN1773509B (en) * | 2004-11-12 | 2010-12-22 | 微软公司 | Computer file system |
| CN101930466A (en) * | 2010-08-31 | 2010-12-29 | 北京捷通华声语音技术有限公司 | Method and system for managing cross-platform memory file |
| CN101430700B (en) * | 2007-10-16 | 2011-06-22 | 巴比禄股份有限公司 | File management device and storage device |
| CN102184260A (en) * | 2011-06-09 | 2011-09-14 | 中国人民解放军国防科学技术大学 | Method for accessing mass data in cloud calculation environment |
| CN1731527B (en) * | 2004-08-06 | 2011-11-16 | 联发科技股份有限公司 | Method and apparatus for data recording with virtual combination |
| CN102253898A (en) * | 2011-07-22 | 2011-11-23 | 杭州海康威视数字技术股份有限公司 | Memory management method and memory management device of image data |
| CN102609365A (en) * | 2012-02-15 | 2012-07-25 | 合一网络技术(北京)有限公司 | Virtual disk system and file storage method based on virtual disk system |
| CN103020186A (en) * | 2012-11-30 | 2013-04-03 | 广东欧珀移动通信有限公司 | File searching method, device and equipment based on embedded device |
| CN103139416A (en) * | 2011-11-21 | 2013-06-05 | 夏普株式会社 | Information processing device and multifunction peripheral |
| CN103279511A (en) * | 2013-05-16 | 2013-09-04 | 杭州巨峰科技有限公司 | File system for security and protection video monitoring equipment |
| CN103473321A (en) * | 2013-09-12 | 2013-12-25 | 华为技术有限公司 | Database management method and system |
| CN103608783A (en) * | 2011-06-08 | 2014-02-26 | 微软公司 | Storage architecture for backup application |
| CN103970869A (en) * | 2014-05-12 | 2014-08-06 | 浙江宇视科技有限公司 | Large file storage method |
| CN103984640A (en) * | 2014-05-14 | 2014-08-13 | 华为技术有限公司 | Method and device for realizing data prefetching |
| CN104102552A (en) * | 2013-04-15 | 2014-10-15 | 深圳中兴网信科技有限公司 | Message processing method and device |
| CN104461911A (en) * | 2014-07-14 | 2015-03-25 | 北京君正集成电路股份有限公司 | Data storage method and device |
| CN104516988A (en) * | 2015-01-21 | 2015-04-15 | 天津书生云科技有限公司 | File writing method and device |
| US9384201B2 (en) | 2006-03-22 | 2016-07-05 | Samsung Electronics Co., Ltd. | Method of managing data of file system using database management system |
| CN105988891A (en) * | 2015-02-05 | 2016-10-05 | 浙江大华技术股份有限公司 | Magnetic disk data repairing method and device |
| CN106126442A (en) * | 2016-06-17 | 2016-11-16 | 北京京坤倍益科技发展有限公司 | A kind of data store organisation and remote sensing satellite data-storage system |
| CN106980676A (en) * | 2017-03-29 | 2017-07-25 | 江西金格科技股份有限公司 | File management method based on intelligent key disk |
| CN107766445A (en) * | 2017-09-23 | 2018-03-06 | 湖南胜云光电科技有限公司 | A kind of efficient rapid data search method for supporting various dimensions to retrieve |
| CN108108633A (en) * | 2017-12-20 | 2018-06-01 | 中国科学院深圳先进技术研究院 | A kind of data file and its access method, device and equipment |
| CN108197270A (en) * | 2018-01-04 | 2018-06-22 | 中科边缘智慧信息科技（苏州）有限公司 | distributed file system data recovery method |
| CN108459925A (en) * | 2018-02-10 | 2018-08-28 | 深圳市先河系统技术有限公司 | The restorative procedure of private clound equipment and its database, the device with store function |
| US10061711B2 (en) | 2014-09-01 | 2018-08-28 | Huawei Technologies Co., Ltd. | File access method and apparatus, and storage system |
| CN109033231A (en) * | 2018-07-03 | 2018-12-18 | 芜湖威灵数码科技有限公司 | A method of extracting information from multimedia file |
| US10157143B2 (en) | 2014-09-01 | 2018-12-18 | Huawei Technologies Co., Ltd. | File access method and apparatus, and storage system |
| CN109189793A (en) * | 2018-09-13 | 2019-01-11 | 杭州晨晓科技股份有限公司 | A kind of storage of linked list method and device of business datum |
| CN110334541A (en) * | 2019-06-14 | 2019-10-15 | 平安科技（深圳）有限公司 | A kind of method and relevant apparatus of system administration |
| CN111190869A (en) * | 2019-12-27 | 2020-05-22 | 深圳市恒扬数据股份有限公司 | File storage method and terminal |
| CN112306957A (en) * | 2019-07-30 | 2021-02-02 | 华为技术有限公司 | Method and device for acquiring index node number, computing equipment and storage medium |
| CN112379833A (en) * | 2020-11-12 | 2021-02-19 | 阿米华晟数据科技(江苏)有限公司 | File caching device, file caching method, idle space recycling method and fault recovery method |
| CN113377721A (en) * | 2021-07-02 | 2021-09-10 | 电信科学技术第五研究所有限公司 | File table design method for storing files in database |
| CN115328922A (en) * | 2022-10-10 | 2022-11-11 | 北京紫光芯能科技有限公司 | Data management method, device and system for one-way linked list |
-
2003
- 2003-01-14 CN CNB031003400A patent/CN100504854C/en not_active Expired - Fee Related
Cited By (57)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1731527B (en) * | 2004-08-06 | 2011-11-16 | 联发科技股份有限公司 | Method and apparatus for data recording with virtual combination |
| CN1773509B (en) * | 2004-11-12 | 2010-12-22 | 微软公司 | Computer file system |
| CN100347705C (en) * | 2004-12-24 | 2007-11-07 | 北京中星微电子有限公司 | Method for file merge |
| CN100375093C (en) * | 2005-03-18 | 2008-03-12 | 联想(北京)有限公司 | Processing of multiroute processing element data |
| WO2006133597A1 (en) * | 2005-06-15 | 2006-12-21 | Intel Corporation | Using transacted writes and caching mechanism to improve write performance in multi-level cell flash memoty |
| CN100444166C (en) * | 2005-12-16 | 2008-12-17 | 北京中星微电子有限公司 | Position-based interface access method and device for FAT file system |
| US9384201B2 (en) | 2006-03-22 | 2016-07-05 | Samsung Electronics Co., Ltd. | Method of managing data of file system using database management system |
| CN101430700B (en) * | 2007-10-16 | 2011-06-22 | 巴比禄股份有限公司 | File management device and storage device |
| CN100557611C (en) * | 2007-11-15 | 2009-11-04 | 深圳华为通信技术有限公司 | A kind of disposal route of file and device |
| CN101692252A (en) * | 2009-08-31 | 2010-04-07 | 上海宝信软件股份有限公司 | Method for distributing and reclaiming idle blocks of file |
| CN101692252B (en) * | 2009-08-31 | 2014-03-26 | 上海宝信软件股份有限公司 | Method for distributing and reclaiming idle blocks of file |
| CN101789027A (en) * | 2010-03-15 | 2010-07-28 | 江苏大学 | Metadata management method based on DBMS and metadata server |
| CN101930466A (en) * | 2010-08-31 | 2010-12-29 | 北京捷通华声语音技术有限公司 | Method and system for managing cross-platform memory file |
| CN101930466B (en) * | 2010-08-31 | 2012-08-15 | 北京捷通华声语音技术有限公司 | Method and system for managing cross-platform memory file |
| CN103608783A (en) * | 2011-06-08 | 2014-02-26 | 微软公司 | Storage architecture for backup application |
| CN102184260A (en) * | 2011-06-09 | 2011-09-14 | 中国人民解放军国防科学技术大学 | Method for accessing mass data in cloud calculation environment |
| CN102184260B (en) * | 2011-06-09 | 2013-07-10 | 中国人民解放军国防科学技术大学 | Method for accessing mass data in cloud calculation environment |
| CN102253898A (en) * | 2011-07-22 | 2011-11-23 | 杭州海康威视数字技术股份有限公司 | Memory management method and memory management device of image data |
| CN102253898B (en) * | 2011-07-22 | 2013-10-30 | 杭州海康威视数字技术股份有限公司 | Memory management method and memory management device of image data |
| CN103139416A (en) * | 2011-11-21 | 2013-06-05 | 夏普株式会社 | Information processing device and multifunction peripheral |
| CN103139416B (en) * | 2011-11-21 | 2015-07-15 | 夏普株式会社 | Information processing device and multifunction peripheral |
| CN102609365B (en) * | 2012-02-15 | 2015-09-23 | 合一网络技术(北京)有限公司 | A kind of virtual disk system and the file memory method based on virtual disk system |
| CN102609365A (en) * | 2012-02-15 | 2012-07-25 | 合一网络技术(北京)有限公司 | Virtual disk system and file storage method based on virtual disk system |
| CN103020186A (en) * | 2012-11-30 | 2013-04-03 | 广东欧珀移动通信有限公司 | File searching method, device and equipment based on embedded device |
| CN103020186B (en) * | 2012-11-30 | 2016-04-13 | 广东欧珀移动通信有限公司 | A kind of document retrieval method based on embedded device, device and equipment |
| CN104102552A (en) * | 2013-04-15 | 2014-10-15 | 深圳中兴网信科技有限公司 | Message processing method and device |
| CN103279511A (en) * | 2013-05-16 | 2013-09-04 | 杭州巨峰科技有限公司 | File system for security and protection video monitoring equipment |
| US9460186B2 (en) | 2013-09-12 | 2016-10-04 | Huawei Technologies Co., Ltd. | Database management method and system |
| CN103473321A (en) * | 2013-09-12 | 2013-12-25 | 华为技术有限公司 | Database management method and system |
| CN103970869A (en) * | 2014-05-12 | 2014-08-06 | 浙江宇视科技有限公司 | Large file storage method |
| CN103984640A (en) * | 2014-05-14 | 2014-08-13 | 华为技术有限公司 | Method and device for realizing data prefetching |
| CN103984640B (en) * | 2014-05-14 | 2017-06-20 | 华为技术有限公司 | Realize data prefetching method and device |
| CN104461911A (en) * | 2014-07-14 | 2015-03-25 | 北京君正集成电路股份有限公司 | Data storage method and device |
| US10061711B2 (en) | 2014-09-01 | 2018-08-28 | Huawei Technologies Co., Ltd. | File access method and apparatus, and storage system |
| US10157143B2 (en) | 2014-09-01 | 2018-12-18 | Huawei Technologies Co., Ltd. | File access method and apparatus, and storage system |
| CN104516988A (en) * | 2015-01-21 | 2015-04-15 | 天津书生云科技有限公司 | File writing method and device |
| CN104516988B (en) * | 2015-01-21 | 2018-09-28 | 天津书生云科技有限公司 | A kind of file wiring method and device |
| CN105988891B (en) * | 2015-02-05 | 2019-02-12 | 浙江大华技术股份有限公司 | A kind of data in magnetic disk restorative procedure and device |
| CN105988891A (en) * | 2015-02-05 | 2016-10-05 | 浙江大华技术股份有限公司 | Magnetic disk data repairing method and device |
| CN106126442A (en) * | 2016-06-17 | 2016-11-16 | 北京京坤倍益科技发展有限公司 | A kind of data store organisation and remote sensing satellite data-storage system |
| CN106980676A (en) * | 2017-03-29 | 2017-07-25 | 江西金格科技股份有限公司 | File management method based on intelligent key disk |
| CN107766445B (en) * | 2017-09-23 | 2021-06-01 | 湖南胜云光电科技有限公司 | Efficient and rapid data retrieval method supporting multi-dimensional retrieval |
| CN107766445A (en) * | 2017-09-23 | 2018-03-06 | 湖南胜云光电科技有限公司 | A kind of efficient rapid data search method for supporting various dimensions to retrieve |
| CN108108633A (en) * | 2017-12-20 | 2018-06-01 | 中国科学院深圳先进技术研究院 | A kind of data file and its access method, device and equipment |
| CN108108633B (en) * | 2017-12-20 | 2021-07-13 | 中国科学院深圳先进技术研究院 | Data file and access method, device and equipment thereof |
| CN108197270A (en) * | 2018-01-04 | 2018-06-22 | 中科边缘智慧信息科技（苏州）有限公司 | distributed file system data recovery method |
| CN108459925A (en) * | 2018-02-10 | 2018-08-28 | 深圳市先河系统技术有限公司 | The restorative procedure of private clound equipment and its database, the device with store function |
| CN109033231A (en) * | 2018-07-03 | 2018-12-18 | 芜湖威灵数码科技有限公司 | A method of extracting information from multimedia file |
| CN109189793A (en) * | 2018-09-13 | 2019-01-11 | 杭州晨晓科技股份有限公司 | A kind of storage of linked list method and device of business datum |
| CN110334541A (en) * | 2019-06-14 | 2019-10-15 | 平安科技（深圳）有限公司 | A kind of method and relevant apparatus of system administration |
| CN110334541B (en) * | 2019-06-14 | 2024-03-01 | 平安科技（深圳）有限公司 | System management method and related device |
| CN112306957A (en) * | 2019-07-30 | 2021-02-02 | 华为技术有限公司 | Method and device for acquiring index node number, computing equipment and storage medium |
| CN111190869A (en) * | 2019-12-27 | 2020-05-22 | 深圳市恒扬数据股份有限公司 | File storage method and terminal |
| CN112379833A (en) * | 2020-11-12 | 2021-02-19 | 阿米华晟数据科技(江苏)有限公司 | File caching device, file caching method, idle space recycling method and fault recovery method |
| CN113377721A (en) * | 2021-07-02 | 2021-09-10 | 电信科学技术第五研究所有限公司 | File table design method for storing files in database |
| CN115328922A (en) * | 2022-10-10 | 2022-11-11 | 北京紫光芯能科技有限公司 | Data management method, device and system for one-way linked list |
| CN115328922B (en) * | 2022-10-10 | 2022-12-30 | 北京紫光芯能科技有限公司 | Data management method, device and system for one-way linked list |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100504854C (en) | 2009-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1517906A (en) | Document system and document management method | |
| CN1311328C (en) | Storage device | |
| CN100337233C (en) | Transactional file system | |
| CN1295706C (en) | Non-volatile memory, recording apparatus and recording method | |
| CN1132564A (en) | Method and appts. for data storage and retrieval | |
| CN1163899C (en) | Editing device, editing method and recording medium | |
| CN1317116A (en) | Value-instance-connectivity computer-implemented database | |
| CN1292901A (en) | Database apparatus | |
| CN1882906A (en) | System and method for maintaining temporal data in data storage | |
| CN1752947A (en) | Memory storage, storage controlling method, and computer product | |
| CN1761956A (en) | Systems and methods for fragment-based serialization | |
| CN1174319C (en) | Data structure managing device, data structure managing system, data structure managing method, and computer reconded medium for data structure managing program | |
| CN1539144A (en) | Information recording medium, information recording method, information recording device, information reproduction method and information reproduction device | |
| CN1674159A (en) | A semiconductor memory card access apparatus, a computer-readable recording medium, an initialization method, and a semiconductor memory card | |
| CN1690993A (en) | Information processing apparatus, information processing method, program and recording medium used therewith | |
| CN1805049A (en) | Method of data access in nonvolatile storage in embedded system | |
| CN1910558A (en) | Semiconductor memory device and its control method | |
| CN1666196A (en) | Method and mechanism of storing and accessing data and improving performance of database query language statements | |
| CN1705934A (en) | File-update apparatus | |
| CN1203430C (en) | Data management system for using multiple data operation modules | |
| CN101069181A (en) | Storage device and recording medium | |
| CN1942869A (en) | Compound storage, data writing method and program | |
| CN101030223A (en) | Apparatus, method, and computer program for processing information | |
| CN1610879A (en) | Method of optimizing the performance of a computer and a main non-volatile memory unit optimised using specific-use sections | |
| CN1519756A (en) | Record reproduction appts. record reproduction method, computer program and recording medium |
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 | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090624 Termination date: 20210114 |