CN100504854C - 文件管理方法 - Google Patents
文件管理方法 Download PDFInfo
- Publication number
- CN100504854C CN100504854C CNB031003400A CN03100340A CN100504854C CN 100504854 C CN100504854 C CN 100504854C CN B031003400 A CNB031003400 A CN B031003400A CN 03100340 A CN03100340 A CN 03100340A CN 100504854 C CN100504854 C CN 100504854C
- Authority
- CN
- China
- Prior art keywords
- file
- data
- database
- district
- link table
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
一种文件系统及文件管理方法，该文件系统构建在存储介质上，其结构包括数据区，实际文件数据的保存区；元数据区，文件系统建立从物理数据到逻辑数据的映射关系而使用的标志数据的保存区，其特征在于：元数据区保存有每个实际文件在数据区中的数据存储物理位置的单向链表，而使每个实际文件的数据具有唯一的逻辑组合并且通过数据库保存每个单向链表的物理保存区的索引地址而对实际文件进行管理。采用该文件系统的文件管理方法：读取元数据区的数据并组织成数据库文件；数据库访问数据库文件得到单向链表的索引地址而对实际文件进行管理。
Description
技术领域
本发明关于一种用于计算机系统中的文件系统的文件管理方法。
背景技术
文件系统是构建在存储介质的物理分区之上，用以储存文件资料。文件系统是操作系统访问数据的一种重要途径，一段代码或程序访问保存在磁盘或其他存储介质上的数据时，一般情况下总是把请求提交给相应的操作系统，由操作系统根据系统中注册的特定的文件系统的特点把访问请求定位到相应的物理位置，在该物理位置访问相应的实际物理数据并把这些数据按照该文件系统的特点要求组装成逻辑数据结构，此时的数据对于上层应用来讲就是可用的有特定意义的数据了。由此可见高效合理的文件系统对于数据可用性的重要意义。
一般的文件系统为树状目录结构，所谓「树状目录结构」意指系统文件放置的位置整个看起来就像一棵倒过来的树一样，由最上层的「根目录」开始，其下可以有文件，也可以有目录(即微软系统中俗称之「文件夹」)，而各目录下还可以有子目录与文件，如此一路繁衍，形成状似枝叶茂密的大树。而每个文件在此目录树的位置，就称之为「路径(path)」。此树状目录结构的文件配置方式是UNIX的一大创举，之后影响深远，有许多操作系统都采取这样的设计方式，包括当前在windows和linux这两种最常见的计算机操作系统下的许多优秀文件系统，比如windows下的fat、fat32、ntfs，linux下的ext2、ext3，还有主要针对嵌入式领域应用的jfs、reseisfs等文件系统。
但这些文件系统总体来讲是一种通用的文件系统，主要考虑了大多数通用的情况下对文件系统的需求，其数据的组织结构方面有很多优点，但并不能符合所有的需求，特别是在一些特定的应用场合，比如较为特殊的嵌入式应用领域。且这些文件系统结构比较庞杂，占用较多的存储空间，存取查找文件速度慢。
发明内容
本发明要解决的问题提供一种用于计算机系统中的文件系统的文件管理方法，可以快速存取查找文件并适于特定应用领域。
为解决上述问题，本发明文件系统的文件管理方法包括以下步骤：
读取文件系统中元数据区2的数据，并将相关数据组织成数据库文件；所述数据至少包括实际文件数据在数据区中存储物理位置的单向链表以及单向链表的索引地址；根据步骤1)利用数据库访问数据库文件得到单向链表的索引地址；
对根据步骤2)中索引地址得到已有实际文件的单向链表进行操作或建立新的单向链表，进而达成实际文件的管理。
本发明文件系统的文件管理方法具有以下优点：
本发明文件系统的文件管理方法能利用数据库有效提高数据的访问效率。既可以在嵌入式Linux环境下使用，也可以在桌面Linux/Windows环境下使用，并且对于有特定要求的场合，能够较好的满足对数据的访问需求。
附图说明
图1是本发明文件系统的结构示意图。
图2是本发明文件系统的文件系统分区示意图。
图3是本发明文件系统一实施例中的单向链表的示意图。
图4是图3中的单向链表与数据区数据的映射关系示意图。
图5是本发明文件管理方法流程图。
具体实施方式
请参照图1、2所示，本发明文件系统构建在存储介质5上，文件系统所占有存储介质的存储物理区域为该文件系统的文件系统分区1。存储介质5可以是硬盘也可以是其他存储介质51。文件系统分区1可以是硬盘的一个分区或多个分区或整个硬盘。
该文件系统分区1其结构按照确定的格式划分为逻辑上的3个数据区域：
1)元数据区2，文件系统建立从物理数据到逻辑数据的映射关系而使用的标志数据的保存区，即含有文件系统分区1中除了真实文件所包含的数据的保存区以外的文件系统为了建立起从物理数据到逻辑数据的映射关系而使用的标志数据的区域。该区域被特定的接口所访问，并不用于保存实际文件的数据；
2)数据区3，实际文件数据的保存区，建成DATA区3；及
3)元数据区备份区4，以备份元数据区2中的标志数据。
其中物理数据为保存实际文件的物理存储空间相关数据；而逻辑数据则为实际文件所包含的数据。
元数据区2又被划分为4个逻辑数据区域：
1)文件系统分区信息记录区21，记录文件系统的基本信息，简称PIT区21；
2)文件系统已分配簇记录区23，记录实际文件数据在数据区3中存储物理位置的单向链表，简称LAT区23；
3)文件系统文件记录表记录区22，保存实际文件信息以及单向链表的索引地址，简称FDB区22；及
4)文件系统未分配簇记录区24，记录数据区未分配簇所代表的物理存储位置，简称LUT区24。
元数据区2保存有每个实际文件在数据区3中的数据存储物理位置的单向链表即LAT区23的单向链表，而使每个实际文件的数据具有唯一的逻辑组合并且通过数据库保存每个单向链表的物理保存区即FDB区22的索引地址而对实际文件进行管理。
元数据区备份区4，相应地分为：
文件系统文件记录表记录区备份区41，简称FDB-BAK区41；
文件系统已分配簇记录区备份区42，简称LAT-BAK区42；
文件系统未分配簇记录区备份区43，简称LUT-BAK区43；
及
文件系统分区信息记录区备份区44，简称PIT-BAK区44。
元数据区备份区4保存在文件系统分区1的最后，而不是紧接着元数据区2保存，其好处在于一旦元数据区2受到物理损害时，尽可能的减少该物理损害同时损害到元数据区备份区4的可能性。同时，由于PIT区21的数据完整性对整个文件系统非常重要，PIT-BAK区44的位置定义在整个文件系统分区1的最后一个扇区，这也是出于安全备份PIT区21并有利于PIT区21受到损害时对PIT-BAK区44容易定位以恢复整个系统的目的而做出的设计。
下面分别详细描述文件系统分区的各个逻辑数据区域：
a)文件系统分区信息记录区21，简称PIT区21
数据内容：
该区域中保存的数据是文件系统的文件系统分区1的基本信息，包括存储介质的容量、文件系统分区1的起始位置、文件系统分区的大小、元数据区2中各数据区域的起始位置及其大小、数据库文件的数量及其起始位置、大小。该区域是文件系统中定位各部分数据的基础，非常重要。数据库文件包括：索引文件和数据文件，其组成及建立在后续的文件管理方法进行描述。
操作系统或上层应用程序通过对该区域所保存的数据的访问，可以获得文件系统分区1的基本信息，并可以通过这些数据划分开各不同意义的数据区域，在逻辑上建立起文件系统分区1的结构，并且定位数据库的索引文件和数据文件的信息，为查找和访问其他区域及其这些区域中的数据建立了寻址的基础。
数据结构：
struct st_effs_PIT{
//存储介质以及分区标识信息
unsigned int ihdlength；
//硬盘(或其他存储介质)真实容量，以扇区(对其他存储介
质根据存储介质的具体情况而定)为单位；
unsigned int ieffsbegin；
//硬盘(或其他存储介质)文件系统分区1起始位置，以扇区
(对其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ieffslength；
//文件系统分区1容量，以扇区(对其他存储介质根据存储介
质的具体情况而定)为单位；
unsigned int iblocklength；
//文件系统分区1一个物理存储单位的大小，以字节为单位；
unsigned char partname[16]；
//该文件系统分区1的标识名称；
unsigned char part-effs[4]；
//文件系统分区1标志，必须为字串“EFFS”；
//PIT区21的信息
unsigned int ieffsPITbegin；
//文件系统分区信息记录区(PIT区)21的起始位置，以扇区
(对其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ieffsPITlength；
//文件系统分区信息记录区(PIT区)21的长度，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
//PIT-BAK区44的信息
unsigned int ieffsPIT-BAKbegin；
//文件系统分区信息记录区备份区(PIT-BAK区)44起始位
置，以扇区(对其他存储介质根据存储介质的具体情况而定)
为单位；
//FDB区22的信息
unsigned int ieffsFDBbegin；
//文件系统文件记录表记录区(FDB区)22的起始位置，以扇
区(对其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ieffsFDBlength；
//文件系统文件记录表记录区(FDB区)22的长度，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
//FDB-BAK区41的信息
unsigned int ieffsFDB-BAKbegin；
//文件系统文件记录表记录区备份区(FDB-BAK区)41的起
始位置，以扇区(对其他存储介质根据存储介质的具体情况而
定)为单位；
//FDB区22的数据库索引文件信息
unsigned int ifdbindexfilenum；
//FDB区22的数据库索引文件的个数
unsigned int ifdbindexfilebegin；
//FDB区22的数据库第一个索引文件的起始位置，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ifdbindexfilelength；
//FDB区22的数据库第一个索引文件的长度，以扇区(对其
他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ifdbindexfilereserve；
//为以后该结构的升级作保留；
//FDB区22的数据库数据文件信息
unsigned int ifdbdatafilenum；
//FDB区22的数据库数据文件的个数
unsigned int ifdbdatafilebegin；
//FDB区22的数据库第一个数据文件的起始位置，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ifdbdatafilelength；
//FDB区22的数据库第一个数据文件的长度，以扇区(对其
他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ifdbdatafilereserve；
//为以后该结构的升级作保留；
//LAT区23的信息
unsigned int ieffsLATbegin；
//文件系统已分配簇记录区(LAT区)23的起始位置，以扇区
(对其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ieffsLATlength；
//文件系统已分配簇记录区(LAT区)23的长度，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
//LAT-BAK区42的信息
unsigned int ieffsLAT-BAKbegin；
//文件系统已分配簇记录区备份区(LAT-BAK区)42起始位
置，以扇区(对其他存储介质根据存储介质的具体情况而定)
为单位；
//LUT区24的信息
unsigned int ieffsLUTbegin；
//文件系统未分配簇记录区(LUT区)24的起始位置，以扇
区(对其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ieffsLUTlength；
//文件系统未分配簇记录区(LUT区)24的长度，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
//LUT-BAK区43的信息
unsigned int ieffsLUT-BAKbegin；
//文件系统未分配簇记录区备份区(LUT-BAK区)43起始位
置，以扇区(对其他存储介质根据存储介质的具体情况而定)
为单位；
//LUT区24的数据库索引文件信息
unsigned int ilutindexfilenum；
//LUT区24的数据库索引文件的个数
unsigned int ilutindexfilebegin；
//LUT区24的数据库第一个索引文件的起始位置，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ilutindexfilelength；
//LUT区24的T数据库第一个索引文件的长度，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ilutindexfilereserve；
//为以后该结构的升级作保留；
//LUT区24的数据库数据文件信息
unsigned int ilutdatafilenum；
//LUT区24数据库数据文件的个数
unsigned int ilutdatafilebegin；
//LUT区24数据库第一个数据文件的起始位置，以扇区(对
其他存储介质根据存储介质的具体情况而定)为单位；
unsigned int ilutdatafilelength；
//LUT区24数据库第一个数据文件的长度，以扇区(对其他
存储介质根据存储介质的具体情况而定)为单位；
unsigned int ilutdatafilereserve；
//为以后该结构的升级作保留；
//数据区3的信息
unsigned int ieffsDATAbegin；
//文件系统实际文件数据存储区即数据区(DATA区)3的起
始位置，以扇区(对其他存储介质根据存储介质的具体情况而
定)为单位；
unsigned int ieffsDATAlength；
//文件系统文件数据存储区即数据区(DATA区)3的长度，
以扇区(对其他存储介质根据存储介质的具体情况而定)为单
位；
//CRC校验和
unsigned int ieffsCRC；
//以上36个域的数据CRC冗余循环校验和；
} //end the definition of structst_effs_PIT
该数据结构中的FDB/LUT区22/24的数据库索引文件信息数据项和数据库数据文件信息数据项是文件系统中FDB/LUT区22/24的数据库文件信息，每组包含8个数据项，分别为数据库索引文件的个数(ifdb/lutindexfilenum)、数据库第一个索引文件的起始位置(ifdb/lutindexfilebegin)、数据库第一个索引文件的长度(ifdb/lutindexfilelength)、数据库索引文件保留字段(ifdb/lutindexfilereserve)、数据库数据文件的个数(ifdb/lutdatafilenum)、数据库第一个数据文件的起始位置(ifdb/lutdatafilebegin)、数据库第一个数据文件的长度(ifdb/lutdatafilelength)、数据库数据文件保留字段(ifdb/lutdatafilereserve)，如此设计是基于如下的考虑：本实施例中的数据库采用联想软件中心开发的SharkBase嵌入式数据库，因为该数据库满足以下要求，简言之其他数据库满足下面要求也可以被采用：
1)SharkBase嵌入式数据库系统在处理时，把组成相关数据区域的数据保存为数据文件，把对数据库内部表单建立的索引数据保存为索引文件，同时建立相应的数据字典和日志文件；
2)SharkBase嵌入式数据库的组件化特点可以实现功能的定制，由于本发明文件系统的应用环境不需要日志、同步等功能，所以在SharkBase嵌入式数据库中去掉用户数据库对数据字典和日志文件的依赖，这样，用户数据库仅依赖于索引文件和数据文件；
3)对于内容相同的数据，上述的数据文件与索引文件数量并没有明确规定，这与数据库的底层结构和核心算法密切相关，比如，对于只有一个表单的数据内容，当限定在表单中只建立一个索引(即只对一个数据域建立索引)时，根据数据量和数据库核心处理优化算法优化效果，有可能是一个索引文件加一个数据文件，也可能是多个索引文件加一个数据文件，也可能是一个索引文件加多个数据文件，还可能是多个索引文件加多个数据文件；
4)在类似嵌入式的应用环境下，数据量不像桌面应用那样庞大，所以在小数据量的情况下，SharkBase嵌入式数据库能保证数据文件和索引文件的数量均为一个，这对FDB/LUT区22/24中定位和读取数据文件和索引文件提供了便利。考虑到版本的升级，在st_effs_PIT结构中还是定义了ifdbdatafilereserve/ilutdatafilereserve数据域和ifdbindexfilereserve/ilutindexfilereserve数据域，以保留用于以后多数据文件和多索引文件使用。
5)由于数据文件和索引文件会随着文件系统中的文件数目以及物理存储单元的分配情况而变化，所以在FDB/LUT区22/24中对索引文件和数据文件可能最大占用的空间作了限制
FDB/LUT区22/24中索引文件和数据文件占用的空间比例为1:3，且索引文件在前，即：假设有一文件系统分区1的FDB区22大小为10M，则索引文件最大占用前2.5M，数据文件从FDB区中偏移2.5M以后再开始，最大占用7.5M。
根据以上的描述，结构st_effs_PIT中设计了数据库索引文件信息数据项和数据库数据文件信息数据项。
以上的数据结构中当存储介质为硬盘时，该PIT区21将占用一个扇区以保存数据，但存储介质不为硬盘时，根据具体的存储介质对保存数据时的存储单位的划分原则来决定该区域应占用多大空间保存数据，比如，当存储介质为flash的时候，假设其每次读写数据块的大小为1K，则该区域应占用1K大小的一个数据块保存数据，并且数据结构中的各数据区域的单位也均为K。
b)文件系统文件记录表记录区22，简称FDB区22
数据内容：
该区域是文件系统中保存文件信息以及实际文件在文件系统分区1中所占用的物理保存区的索引地址(即该实际文件单向链表的索引地址)等信息的区域，该区域中的数据组成数据库的数据文件和索引文件，其中数据文件的数据域参见表1。数据库引擎将数据库文件的数据读出，并将其组织为数据库中的文件信息记录表，每张表中的各数据域记录相应实际文件的文件名称、绝对路径、文件大小、文件的创建时间、文件的最后访问时间、文件的最后修改时间、文件的属主、文件的访问权限及该实际文件单向链表的索引地址。
其数据文件和索引文件的信息在PIT区21中分别用数据库索引文件的个数(ifdbindexfilenum)、数据库第一个索引文件的起始位置(ifdbindexfilebegin)、数据库第一个索引文件的长度(ifdbindexfilelength)、数据库索引文件保留字段(ifdbindexfilereserve)、数据库数据文件的个数(ifdbdatafilenum)、数据库第一个数据文件的起始位置(ifdbdatafilebegin)、数据库第一个数据文件的长度(ifdbdatafilelength)、数据库数据文件保留字段(ifdbdatafilereserve)来表示。
如果是在windows桌面环境下使用本发明文件系统，则数据库要访问数据库文件时，文件系统提供的接口能够将FDB区22中的拷贝到windows桌面环境下的其他文件系统中以供数据库访问，因为数据库是按文件访问，它无法跳过文件系统直接访问物理存储单元，由于该文件系统不是针对windows桌面环境开发的文件系统，所以windows桌面环境下对文件系统的使用必然是一种特殊用途的使用，此种情况下必然存在与windows桌面环境相匹配的其它类型的文件系统分区。
如果是在嵌入式linux环境下使用该文件系统，文件系统会将FDB区22中的索引文件和数据文件拷贝到嵌入式linux建立的ramfs内存文件系统中以利于数据库访问。
| 数据库域名称 | 绝对路径(文件在文件系统中的绝对路径，包括文件名称，≤256字符) | 文件大小(以字节为单位) |
| 数据库域长度 | 256字节 | 4字节 |
| 数据库域类型 | unsigned char[256] | unsigned int |
| 文件的创建时间(xxxx-xx-xx-xx-xx-xx)年-月-日-时-分-秒 | 文件最后访问时间(xxxx-xx-xx-xx-xx-xx)年-月-日-时-分-秒 | 文件最后修改时间(xxxx-xx-xx-xx-xx-xx)年-月-日-时-分-秒 | 文件的属主≤100字符 |
| 14字节 | 14字节 | 14字节 | 100字节 |
| unsigned char[14] | unsigned char[14] | unsigned char[14] | unsignedchar[100] |
| 文件的访问权限 | 本地存储首地址分配索引(逻辑簇顺序号) | 保留 |
| 2字节 | 4字节 | 616字节 |
| short | unsigned int | unsigned char[616] |
文件的属主：指文件的创建者
文件的访问权限：低字节顺序的0～2bit位分别表示文件属主的读、写、执行权限
低字节顺序的3～5bit位分别表示文件属主所属的组的读、写、执行权限
低字节顺序的6～8bit位分别表示其他组的读、写、执行权限
低字节顺序的9～15bit位保留
本地存储首地址分配索引(逻辑簇顺序号)：记录指该实际文件在文件系统已分配簇记录区23中的单向链表第一个索引块的地址(索引地址)。
表1 文件系统文件记录表记录区22的数据库记录表的域
c)文件系统已分配簇记录区23，简称LAT区23
数据内容：
该区域是整个文件系统实际文件数据区(DATA区)3的索引表，而每个实际文件的索引表为单向链表。该区域中用每4个字节代表DATA区3中的一个物理存储单位(也可称为存储单元)，一个物理存储单位的大小由PIT区21中的iblocklength数据域表示，在存储介质为硬盘的情况下，一个物理存储单位的大小可以是512字节、1K字节、4K字节，在存储介质为其它介质的情况下(如flash)，一个物理存储单位的大小根据具体介质的情况而定并记录在PIT区21中的iblocklength数据域中。
请参照图3所示，每个实际文件在FDB区22中的本地存储首地址分配索引域中记录了一个相应的索引地址，此索引地址即为LAT区23中表示此实际文件在DATA区3中第一个物理存储位置的一个4字节大小的第一索引块，该第一索引块保存的数据为LAT区23中代表此实际文件第二个物理存储位置的第二索引块的地址，第二索引块又保存LAT区23中代表此实际文件第三个物理存储位置的第三索引块的地址，以此类推，建立起一个由一个或多个索引块依序组成的单向列表。此处，物理存储位置为存储单元的地址，即每个索引块代表该实际文件数据的存储单元的地址。
每个单向链表的索引地址为该单向链表的第一索引块的地址；且第多个索引块构成的单向链表。该单向链表指出了该文件在DATA区3的所有物理存储位置，链表的最后一个节点保存的内容为0，而编号为0的索引块总不用于分配给实际文件。这样就能够唯一的表示某一实际文件在文件系统中的存储分配情况，而使该实际文件的数据具有唯一的逻辑组合，通过读取该单向链表代表的DATA区3的物理存储位置的数据，就能实现对该实际文件的访问。
数据结构：
struct st_effs_LAT{
unsigned int ieffsLATlocal；
//本索引块索引编号；
unsigned int ieffsLATnext；
//下一个索引块索引编号；
structst_effs_LAT* sLAT next；
//链表下一节点的头指针；
} //end the definition of structst_effs_LAT
请结合参照图4所示，某一文件的LAT区23数据与DATA区3数据映射关系示意图。
当系统请求访问某一实际文件时，系统向数据库提交该实际文件的文件名和文件所在的路径，数据库根据这些信息进行查找并得到该实际文件在文件系统中的索引地址，根据该索引地址，可以访问文件系统中文件系统已分配簇记录区(LAT区)23，根据LAT区23中的数据建立该实际文件占用物理位置的单向链表，该单向链表表示的文件系统中的物理位置所存储的数据就是该实际文件的实际内容，将这些物理位置所存储的数据组合起来就是该文件，同时可通过数据库得到该实际文件的文件大小、文件的创建时间、文件的最后访问时间、文件的最后修改时间、文件的属主、文件的访问权限等数据。
d)文件系统未分配簇记录区24，简称LUT区24
数据内容：
该区域是记录数据区未分配簇所代表的物理存储位置的区域，数据库引擎将数据库文件中的数据读出，并将未分配存储单元建立未分配簇编号，组织为数据库中的一张未分配簇记录表，且记录未分配簇所代表的物理存储位置。
该区域数据库的访问方法与原理和FDB区22中的数据库的访问方法与原理相同。其数据文件和索引文件的信息在PIT区21中作了定义，分别用数据库索引文件的个数(ilutindexfilenum)、数据库第一个索引文件的起始位置(ilutindexfilebegin)、数据库第一个索引文件的长度(ilutindexfilelength)、数据库索引文件保留字段(ilutindexfilereserve)、数据库数据文件的个数(ilutdatafilenum)、数据库第一个数据文件的起始位置(ilutdatafilebegin)、数据库第一个数据文件的长度(ilutdatafilelength)、数据库数据文件保留字段(ilutdatafilereserve)来表示。
当系统请求为一个新文件提供物理存储位置代表的存储空间时，采用本文件系统包括以下步骤：
d1)获得未被分配物理存储空间的总容量，这是由该数据库文件记录中的总记录条数乘以每个物理存储单元的大小(由PIT区21中的iblocklength数据域表示)得到的；
d2)比较所要添加文件的占用空间与可用的物理存储空间的总容量的大小；
d3)如果小于可用的物理存储空间的总容量，则利用该记录表中的记录得到可被分配簇，每用掉一个记录所表示的物理存储空间，就在该表中删除该条记录；
d4)同时在文件系统已分配簇记录区中，建立该添加文件的单向链表，并且其实际数据完全写到相应的物理存储单元中；
d5)在文件系统文件记录表记录区中为该添加文件相关的文件信息以及单向链表的索引地址。
当系统请求删除一个文件时，采用本文件系统，包括以下步骤：
d1)数据库利用中数据库文件中的索引地址找到该实际文件的单向链表；
d2)根据该单向链表中的每一个索引块所代表的物理存储单元的地址在数据库未分配簇记录表中，为相应的每个物理存储单元建立未分配簇编号；
d3)删除掉该实际文件的文件信息记录表的记录，达成删除保存在文件系统中的该实际文件。
文件系统未分配簇记录区(LUT区)24的数据库表的域如表2所示：
| 数据库域名称 | 未分配簇编号 | 未分配簇实际序号 |
| 数据库域长度 | 4字节 | 4字节 |
| 数据库域类型 | unsigned int | unsigned int |
未分配簇编号：数据库表中的记录编号
未分配簇实际序号：文件系统中未分配簇所占用的物理保存区的索引地址
表2 EFFS文件系统未分配簇记录区(LUT区)24的数据库表的域
e)文件系统实际文件的数据区3，简称DATA区3
该区域是保存文件实际数据的物理存储区，该区域中已经被分配的物理存储单元在LAT区23中根据其属于不同的实际文件在逻辑上组成一条条单向链表，该区域中未被分配的物理存储单元在LUT区24中由一条条的数据库记录表所索引。
f)文件系统文件记录表记录区备份区41，简称FDB-BAK区41
该区域是FDB区22的一个备份，保存FDB区中的全部数据，其大小和内容与FDB区22一样，当由于意外(如非正常断电等)导致FDB区22受到损害无法正常读出其中数据时，可用该区域中的数据代替。每当FDB区22中的数据被更新后，均应对该区域的数据作同步，以保证该区域始终是完整的FDB区22数据的备份。
g)LAT-BAK区42、LUT-BAK区43、PIT-BAK区44的数据及功能与FDB-BAK区41类似，只不过备份的对象分别为LAT区23、LUT区24、PIT-BAK区21，不再赘述。
依据上述的各区域的格式和内容就可建立文件系统。建立文件系统时应该注意的一点是：应该预先确定该格式的分区中最大需要保存多少个文件。这是由于文件的索引依赖数据库FDB区22的记录项个数，而FDB区22记录表中的每一条记录占用1K的空间，如果完全动态建立该文件系统的话，在最坏的情况下，建立的FDB区22数据库占用的空间大小将是DATA区3的两倍以上，以在一个最小物理存储单元为512字节的硬盘分区中建立文件系统为例，即：
假设DATA区3空间大小为xM，则DATA区3共有x*1024*1024/512＝2048x个物理存储单元，如果在最坏的情况下，每个存储单元都代表一个文件，且数据库每条记录的实际保存长度均达到最大的1K，则FDB区22中的数据库记录条数为2048x个，此时FDB中的数据库数据文件的大小至少为2048x*1K＝2xM，再加上索引文件占用的空间，总占用空间将是DATA区3的两倍以上，这会造成较大的空间浪费。
所以该文件系统推荐用户在格式化文件系统时预估需要保存的最大文件数。
综上所述，为本发明文件系统的结构及原理描述，下面描述本发明文件系统的具体实现。
在一台个人电脑中，为了实现对重要文件的安全备份与恢复以及对已经备份的文件进行管理的目的，另外挂一块较小的硬盘，容量为1.2G，该小硬盘上安装一个嵌入式的linux系统，并划分出大小为1G(1024*1024＝1048576K)的一个分区用于对大硬盘上的文件进行备份，该分区被格式化为本发明文件系统分区1。此时机器上有两套操作系统：大硬盘上的windows2000，小硬盘上的嵌入式linux，在这两个系统中均安装SharkBase嵌入式数据库。则：
DATA区3大小：192*(1024*1024-26669)/203≈966532K；
PIT区21大小：512字节＝0.5K；
FDB区22大小：10000*1K*4/3≈13334K；
LAT区23大小：d/128≈7552K
LUT区24大小：d/48≈20137K
假设该文件系统分区1在小硬盘上的开始位置为第x个扇区，则各区域参数如下：
PIT区21起始位置为x+0扇区，长度为1扇区；
FDB区22起始位置为x+1扇区，长度为26668扇区
LAT区23起始位置为x+26669扇区，长度为15104扇区；
LUT区24起始位置为x+41773扇区，长度为40274扇区；
DATA区3起始位置为x+82047扇区，长度为1933064扇区；
FDB-BAK区41起始位置为x+2015111扇区，长度为26668扇区；
LAT-BAK区42起始位置为x+2041779扇区，长度为15104扇区；
LUT-BAK区43起始位置为x+2056883扇区，长度为40274扇区；
PIT-BAK区44起始位置为ieffsbegin+ieffslength-1扇区，长度为1扇区(即该EFFS分区中的最后一个扇区)；
ieffsbegin：PIT区21中记录的该文件系统分区1起始位置；
ieffslength：PIT区21中记录的文件系统分区1容量。
如此就在这块空间上建立了本发明文件系统。该文件系统的使用既能够在此套环境下的windows操作系统中使用，也能够在此套环境下的嵌入式linux操作系统中使用。
请参照图5所示，采用本发明文件系统而进行文件管理的方法，包括以下步骤：
1)执行步骤61，读取元数据区2的数据，并将相关数据组织成数据库文件；
i.读取文件系统分区信息记录区21的数据，得到文件系统基本信息；
ii.读取文件系统文件记录表记录区22的数据，得到基本文件信息及单向链表的索引地址，并组织成相应数据库文件并保存；
iii.读取文件系统未分配簇记录区24的数据，得到数据区3未分配簇所代表的物理存储位置相关信息，并组织成相应数据库文件并保存；
2)执行步骤62，从步骤61中获得该文件系统未分配存储空间总容量，并利用数据库访问数据库文件得到单向链表的索引地址；
3)执行步骤63，根据步骤62)中索引地址得到已有实际文件的单向链表和未被分配物理存储空间的总容量，对已有实际文件的单向链表进行操作或建立新的单向链表，进而达成实际文件的管理；
4)执行步骤64，用数据库更新数据库文件；
5)执行步骤65，同步更新文件系统元数据区2相应数据区域的数据；
6)同步更新元数据区备份区4相应数据区域的数据；
步骤i)-iii)，调用文件系统提供的接口，读取小硬盘上文件分区1中的PIT区21、FDB区22和LUT区24的数据，并将FDB区22和LUT区24的数据提取出来，利用提取出的数据建立四个数据库文件：fdb.dat、fdb.idx、lut.dat、lut.idx，分别为FDB区22和LUT区24数据文件和索引文件。数据库利用数据库文件完成文件管理：访问、修改、添加、删除、恢复等。其中访问、添加、删除文件的操作已在本发明文件系统的原理部分进行描述，而文件修改与文件访问操作类似，不再赘述。
当要恢复以前备份过的一个实际文件时，其文件恢复的操作包括以下步骤：
1)数据库在FDB数据库文件中找到该实际文件索引地址；
2)根据文件系统中LAT区23提供的该实际文件所用的存储单元在文件系统分区1中占用位置的单向链表结构；
3)根据该单向链表结构按顺序将文件系统分区1中该实际文件的一个一个存储单元拷贝到windows系统下的指定地点，就完成了该文件的恢复。
此外，步骤5)、6)，需要经常对数据库文件及元数据区2的数据作同步更新，以保证数据库文件内容的一致性。
另外，在嵌入式linux环境下按照同样的步骤能够实现上述的对文件的添加、删除和复制过程，只不过将fdb.dat、fdb.idx、lut.dat、lut.idx这四个文件建立在ramfs中。
在linux环境下，文件系统分区1被格式化过后即可作为一个可以对文件进行存储和逻辑组织的文件系统来使用，SharkBase嵌入式数据库访问数据库数据文件和数据库索引文件时，调用的文件系统接口会按PIT区21中的数据信息将FDB区22和LUT区24中保存的数据的内容拷贝到ramfs，并将其建立为四个数据库文件：FDB区22数据文件、FDB区22索引文件、LUT区24数据文件、LUT区24索引文件。数据库通过访问这几个数据库文件即可实现对文件系统中的实际文件的访问。数据库对这几个数据库文件的修改将通过文件系统的接口更新到文件系统分区1中的相应的数据区域。
在windows桌面环境下，如果使用SharkBase嵌入式数据库实现该文件系统，则原理与上述相同，唯一的区别在于此时数据库数据文件和数据库索引文件将被创建在windows系统下的可见分区中；如果使用windows下的小型个人数据库access实现该文件系统，则与使用SharkBase嵌入式数据库的不同点在于：此种情况下，由于access只有一个数据库文件，这样在文件系统构建时只要将PIT区21中数据结构的关于数据索引的项赋为0即可。
综上所述，本发明文件系统是个短小精悍的文件系统，而相应文件管理方法操作快速简单。
Claims (18)
1.一种文件管理方法，其特征在于该方法包括如下步骤：
1)读取文件系统中元数据区的数据，并将所读取的数据按照数据库的要求并由该数据库系统组织成数据库文件；所述数据至少包括实际文件数据在数据区中存储物理位置的单向链表以及单向链表的索引地址；
2)根据步骤1)利用数据库访问技术访问所述数据库文件得到单向链表的索引地址；
3)根据步骤2)中索引地址得到已有文件的单向链表，对这些单向链表进行操作，从而实现对文件的管理。
2.如权利要求1所述的文件管理方法，其特征在于：文件系统的元数据区划分为多个逻辑数据区：
文件系统分区信息记录区，记录文件系统的基本信息；
文件系统已分配簇记录区，记录实际文件数据在数据区中存储物理位置的单向链表；
文件系统文件记录表记录区，保存实际文件信息以及单向链表的索引地址；
文件系统未分配簇记录区，记录数据区未分配簇所代表的物理存储位置。
3.如权利要求2所述的文件管理方法，其特征在于：步骤1)进一步包括如下步骤：
a)读取文件系统分区信息记录区的数据，得到文件系统基本信息；
b)读取文件系统文件记录表记录区的数据，得到实际文件信息及单向链表的索引地址，并组织成相应数据库文件并保存；
c)读取文件系统未分配簇记录区的数据，得到数据区未分配簇所代表的物理存储位置相关信息，并组织成相应数据库文件并保存。
4.如权利要求3所述的文件管理方法，其特征在于：文件系统的基本信息包括存储介质的容量、文件系统分区的起始位置、文件系统分区的大小、元数据区中各逻辑分区的起始位置及其大小、数据库文件的数量及其起始位置、大小。
5.如权利要求4所述的文件管理方法，其特征在于：文件信息包括每个实际文件的文件名称、绝对路径、文件大小、文件的创建时间、文件的最后访问时间、文件的最后修改时间、文件的属主、文件的访问权限。
6.如权利要求5所述的文件管理方法，其特征在于：每个实际文件的单向链表由一个或多个索引块依序组成，每个索引块代表该实际文件数据的存储单元的地址。
7.如权利要求6所述的文件管理方法，其特征在于：每个单向链表的索引地址为该单向链表的第一索引块的地址；且第一索引块保存第二索引块的地址；以此类推建构单向链表。
8.如权利要求7所述的文件管理方法，其特征在于：数据库将步骤b)中的数据库文件的数据读出，并将其组织为数据库中的文件信息记录表，每张表中的各数据域记录相应实际文件的文件名称、绝对路径、文件大小、文件的创建时间、文件的最后访问时间、文件的最后修改时间、文件的属主、文件的访问权限及该实际文件单向链表的索引地址。
9.如权利要求8所述的文件管理方法，其特征在于：数据库引擎将步骤c)中数据库文件中的数据读出，并将未分配存储单元建立未分配簇编号，组织为数据库中的一张未分配簇记录表，且记录未分配簇所代表的物理存储位置。
10.如权利要求9所述的文件管理方法，其特征在于：实际文件管理包括添加、恢复、删除文件操作。
11.如权利要求10所述的文件管理方法，其特征在于：添加文件操作包括如下步骤：
根据步骤a)中的信息获得未被分配物理存储空间的总容量；
比较所要添加文件的占用空间与可用的物理存储空间的总容量的大小；
如果小于可用的物理存储空间的总容量，则利用该记录表中的记录得到可被分配簇，每用掉一个记录所表示的物理存储空间，就在该表中删除该条记录；
同时在文件系统已分配簇记录区中，建立该添加文件的单向链表，并且其实际数据完全写到相应的物理存储单元中；
在文件系统文件记录表记录区中为该添加文件添加相关的文件信息以及单向链表的索引地址。
12.如权利要求10所述的文件管理方法，其特征在于：删除文件操作包括如下步骤：
数据库利用步骤b)中数据库文件中的索引地址找到该实际文件的单向链表；
根据该单向链表中的每一个索引块所代表的物理存储单元的地址在数据库未分配簇记录表中，为相应的每个物理存储单元建立未分配簇编号；
删除掉该实际文件的文件信息记录表的记录，从而实现删除保存在文件系统中的该实际文件。
13.如权利要求10所述的文件管理方法，其特征在于：恢复文件的操作包括以下步骤：
数据库在保存实际文件信息以及单向链表的索引地址的FDB数据库文件中找到该实际文件索引地址；
根据文件系统中文件系统已分配簇记录区23简称LAT区23提供的数据建立该实际文件所用的存储单元在文件系统分区1即文件系统所占有存储介质的存储物理区域中占用位置的单向链表结构；
根据该单向链表结构按顺序将文件系统分区1中该实际文件的一个一个存储单元拷贝到windows系统下该文件原先所在的地点，就完成了该文件的恢复。
14.如权利要求1所述的文件管理方法，其特征在于：数据库文件包括索引文件及数据文件存储空间占有比例小于或等于1：3。
15.如权利要求3所述的文件管理方法，其特征在于：步骤a)-步骤c)中读取数据是通过用户使用的操作系统或上层应用访问元数据区获得，并暂时将数据库文件保存到所使用的操作系统的内存文件系统中。
16.如权利要求15所述的文件管理方法，其特征在于：该数据库为嵌入式数据库。
17.如权利要求1所述的文件管理方法，其特征在于：完成步骤3)文件管理操作，同时用数据库更新数据库文件，从而实现同步更新文件系统元数据区相应数据区域的数据。
18.如权利要求17所述的文件管理方法，其特征在于：更新文件系统元数据区时同步更新元数据区备份区相应数据区域的数据。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031003400A CN100504854C (zh) | 2003-01-14 | 2003-01-14 | 文件管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031003400A CN100504854C (zh) | 2003-01-14 | 2003-01-14 | 文件管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1517906A CN1517906A (zh) | 2004-08-04 |
| CN100504854C true CN100504854C (zh) | 2009-06-24 |
Family
ID=34281133
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB031003400A Expired - Fee Related CN100504854C (zh) | 2003-01-14 | 2003-01-14 | 文件管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100504854C (zh) |
Families Citing this family (41)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1731527B (zh) * | 2004-08-06 | 2011-11-16 | 联发科技股份有限公司 | 虚拟合并的数据记录方法及装置 |
| US7730114B2 (en) * | 2004-11-12 | 2010-06-01 | Microsoft Corporation | Computer file system |
| CN100347705C (zh) * | 2004-12-24 | 2007-11-07 | 北京中星微电子有限公司 | 一种合并文件的方法 |
| CN100375093C (zh) * | 2005-03-18 | 2008-03-12 | 联想(北京)有限公司 | 多线程元数据的处理方法 |
| US20080162782A1 (en) * | 2005-06-15 | 2008-07-03 | Nagarajan Suresh | Using Transacted Writes and Caching Mechanism to Improve Write Performance in Multi-Level Cell Flash Memory |
| CN100444166C (zh) * | 2005-12-16 | 2008-12-17 | 北京中星微电子有限公司 | Fat文件系统中基于位置的接口访问方法及其装置 |
| KR100790991B1 (ko) | 2006-03-22 | 2008-01-03 | 삼성전자주식회사 | 데이터베이스 관리 시스템을 이용하여 파일시스템의메타데이터를 관리하는 방법 |
| JP5184041B2 (ja) * | 2007-10-16 | 2013-04-17 | 株式会社バッファロー | ファイルシステム管理装置およびファイルシステム管理プログラム |
| CN100557611C (zh) * | 2007-11-15 | 2009-11-04 | 深圳华为通信技术有限公司 | 一种文件的处理方法和装置 |
| CN101692252B (zh) * | 2009-08-31 | 2014-03-26 | 上海宝信软件股份有限公司 | 文件空闲块的分配和回收方法 |
| CN101789027A (zh) * | 2010-03-15 | 2010-07-28 | 江苏大学 | 一种基于dbms的元数据管理方法和元数据服务器 |
| CN101930466B (zh) * | 2010-08-31 | 2012-08-15 | 北京捷通华声语音技术有限公司 | 跨平台内存文件的管理方法及管理系统 |
| US8868882B2 (en) * | 2011-06-08 | 2014-10-21 | Microsoft Corporation | Storage architecture for backup application |
| CN102184260B (zh) * | 2011-06-09 | 2013-07-10 | 中国人民解放军国防科学技术大学 | 一种云计算环境下的海量数据存取方法 |
| CN102253898B (zh) * | 2011-07-22 | 2013-10-30 | 杭州海康威视数字技术股份有限公司 | 一种图像数据的内存管理方法及装置 |
| JP5474916B2 (ja) * | 2011-11-21 | 2014-04-16 | シャープ株式会社 | 情報処理装置および複合機 |
| CN102609365B (zh) * | 2012-02-15 | 2015-09-23 | 合一网络技术(北京)有限公司 | 一种虚拟磁盘系统和基于虚拟磁盘系统的文件存储方法 |
| CN103020186B (zh) * | 2012-11-30 | 2016-04-13 | 广东欧珀移动通信有限公司 | 一种基于嵌入式设备的文件检索方法、装置以及设备 |
| CN104102552A (zh) * | 2013-04-15 | 2014-10-15 | 深圳中兴网信科技有限公司 | 一种消息处理方法及装置 |
| CN103279511B (zh) * | 2013-05-16 | 2016-06-15 | 杭州巨峰科技有限公司 | 一种安防视频监控设备专用的文件系统 |
| CN103473321A (zh) * | 2013-09-12 | 2013-12-25 | 华为技术有限公司 | 数据库管理方法与系统 |
| CN103970869A (zh) * | 2014-05-12 | 2014-08-06 | 浙江宇视科技有限公司 | 一种大文件存储方法 |
| CN103984640B (zh) * | 2014-05-14 | 2017-06-20 | 华为技术有限公司 | 实现数据预取方法及装置 |
| CN104461911A (zh) * | 2014-07-14 | 2015-03-25 | 北京君正集成电路股份有限公司 | 一种数据存储方式及装置 |
| EP3190520B1 (en) | 2014-09-01 | 2019-08-07 | Huawei Technologies Co. Ltd. | File access method and apparatus, and storage system |
| CN105579977B (zh) | 2014-09-01 | 2020-04-14 | 华为技术有限公司 | 访问文件的方法、装置及存储系统 |
| CN104516988B (zh) * | 2015-01-21 | 2018-09-28 | 天津书生云科技有限公司 | 一种文件写入方法和装置 |
| CN105988891B (zh) * | 2015-02-05 | 2019-02-12 | 浙江大华技术股份有限公司 | 一种磁盘数据修复方法及装置 |
| CN106126442A (zh) * | 2016-06-17 | 2016-11-16 | 北京京坤倍益科技发展有限公司 | 一种数据存储结构和遥感卫星数据存储系统 |
| CN106980676A (zh) * | 2017-03-29 | 2017-07-25 | 江西金格科技股份有限公司 | 基于智能密钥盘的文件管理方法 |
| CN107766445B (zh) * | 2017-09-23 | 2021-06-01 | 湖南胜云光电科技有限公司 | 一种支持多维度检索的高效快速数据检索方法 |
| CN108108633B (zh) * | 2017-12-20 | 2021-07-13 | 中国科学院深圳先进技术研究院 | 一种数据文件及其访问方法、装置及设备 |
| CN108197270B (zh) * | 2018-01-04 | 2021-05-28 | 中科边缘智慧信息科技（苏州）有限公司 | 分布式文件系统数据回收方法 |
| CN108459925B (zh) * | 2018-02-10 | 2022-05-31 | 深圳市先河系统技术有限公司 | 私有云设备及其数据库的修复方法、具有存储功能的装置 |
| CN109033231A (zh) * | 2018-07-03 | 2018-12-18 | 芜湖威灵数码科技有限公司 | 一种从多媒体文件中提取信息的方法 |
| CN109189793A (zh) * | 2018-09-13 | 2019-01-11 | 杭州晨晓科技股份有限公司 | 一种业务数据的链表存储方法及装置 |
| CN110334541B (zh) * | 2019-06-14 | 2024-03-01 | 平安科技（深圳）有限公司 | 一种系统管理的方法及相关装置 |
| CN111190869A (zh) * | 2019-12-27 | 2020-05-22 | 深圳市恒扬数据股份有限公司 | 文件存储方法及终端 |
| CN112379833A (zh) * | 2020-11-12 | 2021-02-19 | 阿米华晟数据科技(江苏)有限公司 | 文件缓存装置、文件缓存、闲置空间回收及故障恢复方法 |
| CN113377721B (zh) * | 2021-07-02 | 2023-03-24 | 电信科学技术第五研究所有限公司 | 一种数据库中存储文件的文件表设计方法 |
| CN115328922B (zh) * | 2022-10-10 | 2022-12-30 | 北京紫光芯能科技有限公司 | 用于单向链表的数据管理方法、装置及系统 |
-
2003
- 2003-01-14 CN CNB031003400A patent/CN100504854C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN1517906A (zh) | 2004-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100504854C (zh) | 文件管理方法 | |
| US9047301B2 (en) | Method for optimizing the memory usage and performance of data deduplication storage systems | |
| US10031675B1 (en) | Method and system for tiering data | |
| CN100483420C (zh) | 基于快照的细粒度文件与目录版本管理方法 | |
| US7487138B2 (en) | System and method for chunk-based indexing of file system content | |
| JP5500309B2 (ja) | ストレージ装置 | |
| US7640262B1 (en) | Positional allocation | |
| US7673099B1 (en) | Affinity caching | |
| CN101501623B (zh) | 感知文件系统的块存储系统、装置和方法 | |
| US7930559B1 (en) | Decoupled data stream and access structures | |
| US8433863B1 (en) | Hybrid method for incremental backup of structured and unstructured files | |
| US20100082545A1 (en) | Compression of sorted value indexes using common prefixes | |
| CN101488153A (zh) | 嵌入式Linux下大容量闪存文件系统的实现方法 | |
| JP2005267600A5 (zh) | ||
| CN100424699C (zh) | 一种属性可扩展的对象文件系统 | |
| US8060481B1 (en) | Time indexed file system | |
| US10496612B2 (en) | Method for reliable and efficient filesystem metadata conversion | |
| CN102982151A (zh) | 多个物理文件合并为一个逻辑文件的方法 | |
| CN110297781B (zh) | 一种基于写时复制来恢复apfs中被删除数据的方法 | |
| CN111475102B (zh) | 一种基于蓝光的对象存储系统及其存储方法 | |
| CN106709014A (zh) | 一种文件系统转换方法及装置 | |
| CN112416879A (zh) | 一种基于ntfs文件系统的块级数据去重方法 | |
| EP4336336A1 (en) | Data compression method and apparatus | |
| CN113535092B (zh) | 用于减少内存元数据的存储引擎、方法和可读介质 | |
| US20230376461A1 (en) | Supporting multiple fingerprint formats for data file segment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090624 Termination date: 20210114 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |