CN102831240B - 扩展元数据文件的存储方法和存储结构 - Google Patents
扩展元数据文件的存储方法和存储结构 Download PDFInfo
- Publication number
- CN102831240B CN102831240B CN201210326639.XA CN201210326639A CN102831240B CN 102831240 B CN102831240 B CN 102831240B CN 201210326639 A CN201210326639 A CN 201210326639A CN 102831240 B CN102831240 B CN 102831240B
- Authority
- CN
- China
- Prior art keywords
- file
- layout
- index node
- record
- fundamental block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了扩展元数据文件的存储方法和存储结构，其中，该方法包括：当文件的布局超出索引节点的大小时，形成布局扩展文件；以及将布局扩展文件存储在元数据文件中与索引节点相对应的记录基本块中。通过这种技术方案，避免了底层文件系统ext3下单目录文件数目过多的问题。
Description
技术领域
本发明涉及分布式文件领域，更具体地，涉及扩展元数据文件的存储方法和存储结构。
背景技术
Parastor(本申请的发明人所开发的分布式文件系统的名称)是一个分布式文件系统，其中包含元数据服务器oPara、数据服务器oStor以及客户端oApp等多个模块。
oPara中的元数据组织方式为：基本元数据信息的存放单元为文件(我们称之为mfile)，每个mfile中存放8192个inode(索引节点)及其相关信息(包括inode位图信息(标记对应inode是否有效))以及8192个目录的基本块及基本索引(目录dentry项采用扩展hash方式组织)，oPara内存以private方式将磁盘文件映射入内存，磁盘文件的写入由日志系统完成。
Parastor对文件的存储方式是将文件分成多个固定长度的对象以提高文件的读写性能，由于对象长度固定，随着文件的增长，对象数目越来越多，文件的layout(记录对象所在的磁盘及对象状态)就会越来越大，当超出inode固定大小时，就会产生扩展元数据。Parastor原来的做法是将文件扩展元数据存储在一个独立的扩展文件中(layout超出inode固定大小时，产生扩展文件，inode中的layout废弃，所有layout都放入扩展文件)，并且对layout的修改需要对整个inode记录日志。此外，由于map针对文件实际长度进行，所以对layout的每次扩展都要重新map扩展文件。在图1中示出了元数据的组织结构。
然而，原来实现方法存在如下缺点：
1)如果一个文件系统内每个用户文件都比较大，即每个文件的元数据都存在扩展文件，那么单个元数据目录下的文件数目可能会超出ext3的限制(ext3为元数据的底层文件系统)；
2)每次扩展layout都要重新map扩展文件，使map、unmap操作比较频繁，增加了代码错误处理的复杂度；
3)每次记录日志都有大量的冗余信息，给日志系统及网络造成比较大的负担。
针对相关技术中的问题，目前尚未提出有效的解决方案。
发明内容
针对相关技术中的问题而做出本发明，其能够解决目录文件数目过多、代理错误处理较为复杂且网络负担较重的问题。
根据本发明的一个方面，提供了一种扩展元数据文件的存储方法，包括以下步骤：当文件的布局超出索引节点的大小时，形成布局扩展文件；以及将布局扩展文件存储在元数据文件中与索引节点相对应的记录基本块中。
优选地，将布局扩展文件存储在记录基本块之后，索引节点中不再存储布局。
优选地，当布局扩展文件大于记录基本块而无法进行存储时，生成单独的扩展文件来存储布局扩展文件。
优选地，生成单独的扩展文件之后，记录基本块不再存储布局扩展文件。
优选地，布局扩展文件以页为单位进行映射。
优选地，将针对索引节点的修改进行分类，使得只针对修改的部分记录日志。
优选地，对索引节点的修改包括属性修改，使得只针对属性部分记录日志。
优选地，对索引节点的修改包括布局修改，使得只针对变化对象记录日志。
根据本发明的另一方面，提供了一种扩展元数据文件的存储结构，包括：索引节点数据块，存储多个索引节点及其相关信息；以及记录基本块，存储多个目录信息或者多个布局扩展文件。
优选地，当布局扩展文件大于记录基本块中的对应记录基本块时，存储结构还包括单独的扩展文件来存储无法记录在记录基本块中的布局扩展文件。
通过本发明的技术方案，避免了底层文件系统ext3下单目录文件数目过多的问题，简化了映射扩展文件的处理，并且降低了日志及网络压力。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是根据现有技术的元数据文件的结构的示意图；
图2是根据本发明的扩展元数据文件的存储方法的流程图；
图3是根据本发明的扩展元数据文件的存储结构的示意图；以及
图4是根据本发明实施例的扩展元数据文件的存储方法的布局扩展的流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。
图2是根据本发明的扩展元数据文件的存储方法的流程图；
参照图1，根据本发明的扩展元数据文件的存储方法包括以下步骤：S202，当文件的布局超出索引节点的大小时，形成布局扩展文件；以及S204，将布局扩展文件存储在元数据文件中与索引节点相对应的记录基本块中。
优选地，将布局扩展文件存储在记录基本块之后，索引节点中不再存储布局。
优选地，当布局扩展文件大于记录基本块而无法进行存储时，生成单独的扩展文件来存储布局扩展文件。
优选地，生成单独的扩展文件之后，记录基本块不再存储布局扩展文件。
优选地，布局扩展文件以页为单位进行映射。
优选地，将针对索引节点的修改进行分类，使得只针对修改的部分记录日志。
优选地，对索引节点的修改包括属性修改，使得只针对属性部分记录日志。
优选地，对索引节点的修改包括布局修改，使得只针对变化对象记录日志。
图3是根据本发明的扩展元数据文件的存储结构的示意图。
参见图3，根据本发明的扩展元数据文件的存储结构包括：索引节点数据块，存储多个索引节点及其相关信息；以及记录基本块，存储多个目录信息或者多个布局扩展文件。
优选地，当布局扩展文件大于记录基本块中的对应记录基本块时，存储结构还包括单独的扩展文件来存储无法记录在记录基本块中的布局扩展文件。
具体地，针对现有技术的缺点，申请人提出了新的扩展元数据文件的存储方法及日志记录方式：具体采取以下几种措施：
1)当文件layout超出inode固定大小时，首先将其放入mfile记录基本块的对应位置(该位置对每个inode都有预留，但目前只有目录使用，我们称之为mbody)，如果layout超出mbody再将其全部记录入单独扩展文件；
2)当生成单独的扩展文件时，扩展文件映射以页为单位，当layout进行扩展时，只有当前页不能容纳本次扩展部分时才需要重新映射扩展文件；以及
3)将对inode的修改进行分类，分为属性修改及layout修改，对属性的修改只对属性部分记录日志，对layout修改则只对变化对象记录日志。
注意，为了方便操作，layout由inode→mbody以及由mbody→扩展文件都是全部转移，使用时由inode内存指针指向，不用加以区分。
应该强调的是，本发明解决与扩展元数据文件相关的问题，因此图1和图3中涉及到的dir数据、exthash基本布局等组织结构并不属于本发明的范畴并且它们属于本领域的公知常识，因此在本文中省略它们的详细描述。
图4是根据本发明实施例的扩展元数据文件的存储方法的布局扩展的流程图。
参见图4，首先判定当前位置是否能够存储扩展后的layout。如果可以，则将扩展后的layout记录在当前位置中。
如果当前位置不能够存储扩展后的layout，则将扩展后的layout存储到mbody中并进行相应处理。
如果mbody也不能够存储扩展后的layout，则创建单独的扩展文件并将扩展后的layout存储到所创建的扩展文件中。
创建单独的扩展文件之后，将layout从mbody拷贝到扩展文件中，并且进行相应的映射操作和记录日志操作。
通过本发明的技术方案，与现有技术相比，实现了以下优点：
1)按照对象固定大小64M，对象两副本计算，mbody(4块)可以存放2K个对象，即用户文件超过128G时才有可能用到扩展文件，这可以满足大部分应用的要求，很好的避免了oPara底层文件系统ext3下单目录文件数目过多的问题；
2)扩展文件映射以页为单位，不用每次扩展layout都重新映射扩展文件，简化了处理；以及
3)日志记录以属性和对象为单位，没有了冗余信息，降低了日志及网络压力。
综上所述，借助于本发明的上述技术方案，将inode扩展数据优先考虑放在已存在的文件中来节省生成的ext3文件数目；扩展文件映射不以文件实际长度为单位，而采用以页为最小单元的方式，简化了处理过程；以及日志记录以属性和对象为单位，在不增加处理复杂度的情况下消除冗余信息记录。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (9)
1.一种扩展元数据文件的存储方法，其特征在于，所述方法包括以下步骤：
当文件的布局超出索引节点的大小时，形成布局扩展文件；以及
将所述布局扩展文件存储在元数据文件中与所述索引节点相对应的记录基本块中，
其中，针对所述索引节点的修改进行分类，使得只针对修改的部分记录日志。
2.根据权利要求1所述的方法，其特征在于，将所述布局扩展文件存储在所述记录基本块之后，所述索引节点中不再存储所述布局。
3.根据权利要求1所述的方法，其特征在于，当所述布局扩展文件大于所述记录基本块而无法进行存储时，生成单独的扩展文件来存储所述布局扩展文件。
4.根据权利要求3所述的方法，其特征在于，生成单独的扩展文件之后，所述记录基本块不再存储所述布局扩展文件。
5.根据权利要求3所述的方法，其特征在于，所述布局扩展文件以页为单位进行映射。
6.根据权利要求1所述的方法，其特征在于，对所述索引节点的修改包括属性修改，使得只针对属性部分记录日志。
7.根据权利要求1所述的方法，其特征在于，对所述索引节点的修改包括布局修改，使得只针对变化对象记录日志。
8.一种扩展元数据文件的存储装置，其特征在于，所述存储装置包括：
索引节点数据块，存储多个索引节点及其相关信息；以及
记录基本块，存储多个目录信息或者多个布局扩展文件，
其中，针对所述索引节点的修改进行分类，使得只针对修改的部分记录日志。
9.根据权利要求8所述的存储装置，其特征在于，当所述多个布局扩展文件中的至少一个大于所述记录基本块中的对应记录基本块时，所述存储装置还包括单独的扩展文件来存储无法记录在所述记录基本块中的布局扩展文件。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210326639.XA CN102831240B (zh) | 2012-09-05 | 2012-09-05 | 扩展元数据文件的存储方法和存储结构 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210326639.XA CN102831240B (zh) | 2012-09-05 | 2012-09-05 | 扩展元数据文件的存储方法和存储结构 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102831240A CN102831240A (zh) | 2012-12-19 |
| CN102831240B true CN102831240B (zh) | 2016-03-30 |
Family
ID=47334375
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210326639.XA Active CN102831240B (zh) | 2012-09-05 | 2012-09-05 | 扩展元数据文件的存储方法和存储结构 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102831240B (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103207916B (zh) * | 2013-04-24 | 2017-09-19 | 曙光信息产业(北京)有限公司 | 元数据处理的方法和装置 |
| CN105224607B (zh) * | 2015-09-06 | 2019-05-24 | 浪潮(北京)电子信息产业有限公司 | 一种模拟云存储设备的虚拟文件系统设计方法 |
| CN116383165B (zh) * | 2023-06-03 | 2023-08-11 | 浙江档安科技有限公司 | 一种适应性写入的档案保存方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101446984A (zh) * | 2009-01-09 | 2009-06-03 | 成都市华为赛门铁克科技有限公司 | 一种文件存储方法、装置及文件删除方法和装置 |
| CN101567001A (zh) * | 2009-05-22 | 2009-10-28 | 清华大学 | 并行文件系统的元数据文件布局管理方法 |
-
2012
- 2012-09-05 CN CN201210326639.XA patent/CN102831240B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101446984A (zh) * | 2009-01-09 | 2009-06-03 | 成都市华为赛门铁克科技有限公司 | 一种文件存储方法、装置及文件删除方法和装置 |
| CN101567001A (zh) * | 2009-05-22 | 2009-10-28 | 清华大学 | 并行文件系统的元数据文件布局管理方法 |
Non-Patent Citations (1)
| Title |
|---|
| 加快分布式文件系统元数据访问的研究与实现;李相娜等;《微处理机》;20080430(第02期);第120-122页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102831240A (zh) | 2012-12-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102821138B (zh) | 一种适用于云存储系统的元数据分布式存储方法 | |
| CN102222085B (zh) | 一种基于相似性与局部性结合的重复数据删除方法 | |
| CN104408091B (zh) | 分布式文件系统的数据存储方法及系统 | |
| CN101777017B (zh) | 一种连续数据保护系统的快速恢复方法 | |
| CN106201771B (zh) | 数据存储系统和数据读写方法 | |
| CN103955530B (zh) | 一种在线重复数据删除系统的数据重建优化方法 | |
| CN102033924B (zh) | 一种数据存储方法和系统 | |
| CN104881466B (zh) | 数据分片的处理以及垃圾文件的删除方法和装置 | |
| CN105302668B (zh) | 一种优化对象存储系统中块设备数据访问性能的方法 | |
| CN103544045A (zh) | 一种基于hdfs的虚拟机镜像存储系统及其构建方法 | |
| CN102521330A (zh) | 一种桌面虚拟化环境下的镜像分布式存储方法 | |
| CN101963982A (zh) | 基于位置敏感哈希的删冗存储系统元数据管理方法 | |
| CN106547641A (zh) | 一种基于卷的cdp备份方法 | |
| CN105138275B (zh) | 一种Lustre存储系统数据共享方法 | |
| CN110968554A (zh) | 一种基于文件链分块的区块链存储方法、存储系统及存储介质 | |
| CN109144406A (zh) | 分布式存储系统中元数据存储方法、系统及存储介质 | |
| CN104536908B (zh) | 一种面向单机的海量小记录高效存储管理方法 | |
| CN103473258A (zh) | 云存储文件系统 | |
| US20170083537A1 (en) | Mapping logical identifiers using multiple identifier spaces | |
| CN103279489A (zh) | 一种元数据的存储方法、装置 | |
| CN102831240B (zh) | 扩展元数据文件的存储方法和存储结构 | |
| CN102722450B (zh) | 一种基于位置敏感哈希的删冗块设备存储方法 | |
| CN107368545B (zh) | 一种基于Merkle Tree变形算法的去重方法及装置 | |
| CN106708911A (zh) | 一种云环境下数据文件同步的方法和装置 | |
| CN107506466A (zh) | 一种小文件存储方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C53 | Correction of patent of invention or patent application | ||
| CB02 | Change of applicant information |
Address after: 100193 Beijing, Haidian District, northeast Wang West Road, building 8, No. 36 Applicant after: Dawning Information Industry (Beijing) Co.,Ltd. Address before: 100193 Shuguang building, Zhongguancun Software Park, Haidian District, Beijing Applicant before: Dawning Information Industry (Beijing) Co.,Ltd. |
|
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220726 Address after: 100089 building 36, courtyard 8, Dongbeiwang West Road, Haidian District, Beijing Patentee after: Dawning Information Industry (Beijing) Co.,Ltd. Patentee after: DAWNING INFORMATION INDUSTRY Co.,Ltd. Address before: 100193 No. 36 Building, No. 8 Hospital, Wangxi Road, Haidian District, Beijing Patentee before: Dawning Information Industry (Beijing) Co.,Ltd. |
|
| TR01 | Transfer of patent right |