CN114048185B - 一种分布式文件系统中海量小文件透明打包存储与访问的方法 - Google Patents
一种分布式文件系统中海量小文件透明打包存储与访问的方法 Download PDFInfo
- Publication number
- CN114048185B CN114048185B CN202111367066.0A CN202111367066A CN114048185B CN 114048185 B CN114048185 B CN 114048185B CN 202111367066 A CN202111367066 A CN 202111367066A CN 114048185 B CN114048185 B CN 114048185B
- Authority
- CN
- China
- Prior art keywords
- directory
- file
- packaging
- metadata
- data
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/172—Caching, prefetching or hoarding of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0608—Saving storage space on storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
本发明公开了一种分布式文件系统中海量小文件透明打包存储与访问的方法,该方法包括以下步骤:S1目录打包模块根据预设的打包策略选择满足条件的普通目录,对目录实施打包操作;S2打包目录透明访问模块,发现上层应用发起文件操作时,客户端判断该操作的目标处于一个打包目录之下的子目录或者文件,则将该操作转发至打包目录透明访问模块来处理;S3重打包模块对系统内所有打包目录进行检查,判断其是否满足重新打包的条件,如满足则对其进行重新打包。该存储与访问的方法能够解决传统方法空间有效率低、存储性能低的问题,从而达到有效的提升分布式文件系统所支持的文件数量及数据存储与访问效率的目的。
Description
技术领域
本发明涉及海量小文件存储与管理技术领域,具体来说,涉及一种分布式文件系统中海量小文件透明打包存储与访问的方法。
背景技术
近年来,随着各种新技术及应用的发展,数据总量呈指数型增长,数据存储技术的各个领域都受到了挑战,其中,以海量小文件问题最为突出。这类问题通常发生在以处理图片、文本、日志等类型数据的应用中,例如:医疗影像、Web 2.0 网站、传感器网络、人工智能等。这类应用的特点是文件数量巨大,通常可达亿级别,甚至更高,但单个文件却相对较小,文件大小的范围在数 KB 到 MB 之间,因为被统称为海量小文件应用。
传统存储在应对此类应用时,存储效率会大幅下降,主要表现在两个方面:
1. 空间有效率降低:
存储系统的底层存储介质通常以块为单位存储数据,当文件数据小于一个块时,文件系统通常将其当作整块来存储,超过数据大小的块内空间置空,无法得到使用,从而白白浪费,由于文件普遍较小,这种块内空间浪费的情况在海量小文件场景中更为严重,使得存储系统空间有效率大幅下降;
2. 存储性能降低:
首先,由于底层存储介质按块读写,小文件环境下,系统存取性能的一部分则被块内置空数据所空耗,即,整块读写的数据中,只有部分数据是有效的文件数据。同时,海量小文件应用数据访问模式是典型的随机细碎读写,而底层块设备(无论机械磁盘还是 SSD)的随机读写性能相对于其顺序读写性能则大打折扣,特别是机械磁盘,其随机访问能力最终受限于磁头的机械动作,在大量并发随机读写时,存取性能呈数量级地下降。
对于上述问题,传统存储很难有优化的空间,系统性能的提升只能依靠底层存储介质,即磁盘的数量和单盘性能的提升,但传统存储受限于架构,扩展能力有限,一定数据规模之上时就无法应对。分布式文件系统由于采用高可扩展的体系架构,可在系统中整合更大数量的磁盘,近年来,已逐渐成为解决海量小文件问题的首选技术,但其本质只是依赖磁盘数量的增多来应对海量文件,在数据规模进一步扩大时,上述问题依然存在。例如:在人像比对应用中,单个分布式文件系统可能需要存储百亿级别的小图片文件,因为文件数量过大,无论采取何种实现方式,分布式文件系统的元数据管理和服务效率均会大幅下降,进一步降低小文件读写效率,同时,由于最终数据要按块写入底层存储介质,分布式文件系统中海量小文件的存储效率也并未得到改善,而且还可能因为分布式文件系统特有的副本、纠删码的数据保护机制的引入,使问题进一步的恶化。
鉴于存储系统本身难以有效解决海量小文件应用问题,一些系统尝试从方案和应用层面进行优化。这些技术包括:分区存储和打包存储。
所谓分区存储是从应用角度出发,将单个数据集根据应用需求按照目录划分为若干个较小的区,每个区的数据存储于一个存储系统中,需要使用多个存储系统来保存所有应用数据,降低单个存储系统内文件数量以来保证读写效率。应用程序在访问数据时,应显式的根据区划分选择不同的存储系统来访问数据。这种方式能一定程度上保证小文件读写性能,但仍然无法提升存储空间利用率,并且无法实现单一系统映象的透明文件操作,需要应用显式地主动进行数据分区。
打包存储同样由应用发起,将系统中的小文件按照某种既定格式打包为多个较大的文件进行存储,以降低整个存储系统文件数量。应用需要访问已打包的小文件时,需要显式的对对应打包文件进行解包,才能对其中文件进行读写。通常只适于数据冷热特征明显的应用,打包不再被经常修改和访问的冷数据。显而易见,这种方式一定程度上提升了存储空间利用率,但同样不支持对打包文件透明访问,即应用无法直接访问打包后的小文件,打包后数据的读取和修改操作均相当繁琐且开销极大。
发明内容
针对相关技术中的上述技术问题,本发明提出一种分布式文件系统中海量小文件透明打包存储与访问的方法,能够克服现有技术的上述不足。
为实现上述技术目的,本发明的技术方案是这样实现的:
一种分布式文件系统中海量小文件透明打包存储与访问的方法,包括以下步骤:
S1目录打包流程:目录打包模块对分布式文件系统内存储小文件的普通目录进行后台打包操作,将该普通目录内所有文件和目录的元数据和数据整合存储为元数据打包文件和数据打包文件,生成打包目录,并替换该普通目录;
S2打包目录透明访问流程:打包目录透明访问模块嵌入分布式文件系统客户端的文件访问流程中,上层应用以原目录路径和访问方式访问打包目录时,由打包目录透明访问模块处理该访问请求,将原目录请求映射为面向打包目录及其内所保存的元数据打包文件和数据打包文件的操作,并返回与原目录一致的操作结果;
S3重打包流程:重打包模块对分布式文件系统内打包文件进行重新打包,整合打包目录生成后所进行的文件和目录的修改,重新生成元数据打包文件和数据打包文件。
进一步的,所述S1包括以下步骤:
S11目录打包模块对分布式文件系统内所有相关目录进行遍历,并将目录的属性与打包策略中的打包条件进行比对,将满足条件的目录筛选出来形成打包目录列表,打包策略规定了目录满足打包的条件,由用户事先设定;
S12对打包目录列表中的所有目录,逐个或者并发的执行S13至S15,如果列表为空,直接进入S16;
S13针对一个普通目录开始打包,首先创建一个临时目录,作为原目录打包后的数据暂存位置;
S14发起对原目录的遍历操作,逐级对目录内的所有子目录和文件进行打包处理,在临时目录内生成元数据打包文件和数据打包文件,元数据打包文件记录了该目录内所有子目录和文件的元数据信息,数据打包文件整合存储了目录内所有文件数据,以下是遍历时对单个目录和文件的具体打包操作:对于一个目录,直接将其元数据信息连同该目录所有目录项信息组成一个元数据打包单元,并将该打包单元顺序写入元数据打包文件末尾;对于一个文件,首先要将文件的数据顺序的写入到数据打包文件末尾,并记录写入时的初始位置offset,然后将该文件的所有元数据读出,去掉其中原有的数据分布信息,替换成offset,将新的文件元数据组成元数据打包单元,并写入元数据打包文件末尾;
S15遍历完成后,修改临时目录的属性为“打包目录”Archive,访问元数据服务器,使用临时目录替换原目录,即:将原目录删除,并将临时目录更名为原目录名;
S16等待预先设定的时间周期,转向步骤S11。
进一步的,所述S2包括以下步骤:
S21判断该打包目录的元数据内容是否已经被加载至客户端缓存,如已加载,执行S22;
S22读取打包目录内的元数据打包文件,将所有文件和目录的元数据信息加载在客户端的缓存中,并采用特定数据结构重建整个打包目录的原目录树;
S23根据上层应用文件系统操作的目标和类型,选择执行:S231元数据写流程、S232元数据读流程、S233数据写流程以及S234数据读流程。
进一步的,所述S23中S231元数据写流程包括以下步骤:
S2311根据元数据操作的目录或文件的路径名,在打包目录内重建该路 径,重建过程中,按照路径中的各级目录,逐级在打包目录内检查是否已经存在,如不存在并且不在其父目录的.deleted 目录中,则按照客户端缓存中对应目录的属性生成对应目录,直至最低一级目录,如果存在于其父目录的.deleted 目录中,则直接返回应用操作目标不存在,目录重建时不包含其目录项;
S2312如果重建的最低一级为文件,从客户端缓存中依照原文件属性创建同名新文件,并将原文件的数据从数据打包文件对应位置读取,写入新建文件,重建原文件为打包目录下的普通文件;
S2313被操作的目录和文件被重建后,如果元数据操作类型不是删除,则直接在重建目录和文件上进行操作,并将操作结果返回;
S2314如果元数据操作为目录或文件删除,判断被删除的目录/文件之前是否存在于打包目录对应原目录中,如果存在,则在删除时,将该目录/文件移动至其重建后的父目录下的特殊目录.deleted中,重建目录下的.deleted为系统保留目录,保存目录下被删除的打包目录项,如果不存在,则直接在重建目录和文件上进行操作,并返回操作结果。
进一步的,所述S23中S232元数据读流程包括以下步骤:
S2321检查被操作目录和文件是否已经被重建为普通目录和文件,如果未被重建,转到S2322;如果已被重建,判断操作是否为获取目录的目录项,如果不是则直接读取重建目录或文件的元数据信息并返回;如果是,则首先获取缓存中原目录中的目录项内容,并将重建目录下.deleted 目录中对应的目录项从中删除,然后再合并重建目录下当前的目录项,将最终结果返回上层应用;
S2322检查其父目录是否已经被重建,如果其父目录未重建,转到S2323,如果已重建,在其重建父目录的.deleted 目录下查找目标目录或文件是否存在,如果不存在,转到S2323,如果存在,则返回上层应用,提示错误该目录/文件不存在;
S2323在客户端缓存中直接查找目标目录或文件,并将缓存中对应的元数据信息返回。
进一步的,所述S23中S233数据写流程包括以下步骤:
S2331根据数据操作文件的路径名,判断该文件是否已经在打包目录内被重建,如果已经被重建,转到S2333,如果未重建,在打包目录内重建该文件,重建过程中,按照路径中的各级目录,逐级在打包目录内检查是否已经存在,如不存在,则按照客户端缓存中对应目录的属性生成对应目录,直至最低一级目录,如果重建目录或文件存在于其父目录.deleted 目录中,则直接返回上层应用,被访问的目录/文件不存在,创建目录时不包含其目录项;
S2332从客户端缓存中依照原文件属性创建同名新文件,并将原文件的数据从数据打包文件对应位置读取,写入新建文件,重建原文件为打包目录下的普通文件;
S2333对重建后的文件执行上层应用发起的数据写请求,并将结果返回。
进一步的,所述S23中S234数据读流程包括以下步骤:
S2341检查被操作文件是否已经被重建,如果未被重建,转到S2342,如果已被重建,直接对重建目录执行数据读操作,并返回结果;
S2342检查其父目录是否已经被重建,如果其父目录未重建,转到S2343,如果已重建,在其重建父目录的.deleted 目录下查找目标文件是否存在,如果存在,则返回上层应用该目录/文件不存在,如果不存在,则转到S2343;
S2343在客户端缓存中直接查找目标文件元数据信息,获取文件的布局信
息Layout和文件大小,在打包目录下的数据打包文件中,按照 Layout 信息以及读操作的参数完成数据读操作,并返回结果。
进一步的,所述S3包括以下步骤:
S31 重打包模块对文件系统内所有打包目录进行检查,判断打包目录内重建目录和文件数量与原打包目录相比是否达到了预设比例,所有达到比例的目录组成重打包目录列表,如果列表为空,直接进入S36;
S32对重打包目录列表中的所有目录,逐个或者并发的执行S33至S35进行重打包操作;
S33创建一个临时目录,作为原目录打包后的数据暂存位置;
S34发起对原打包目录的遍历操作,该操作应用所述S2中元数据读流程与数据读流程,逐级对打包目录内的所有子目录和文件进行打包处理,在临时目录内生成元数据打包文件和数据打包文件,元数据打包文件记录了该目录内所有子目录和文件的元数据信息,数据打包文件整合存储了目录内所有文件数据,以下是遍历时对单个目录和文件的具体打包操作:对于一个目录,直接将其元数据信息连同该目录所有目录项信息组成一个元数据打包单元,并将该打包单元顺序写入元数据打包文件末尾;对于一个文件,首先要将文件的数据顺序的写入到数据打包文件末尾,并记录写入时的初始位置offset,然后将该文件的所有元数据读出,去掉其中原有的数据分布信息,替换成 offset,将新的文件元数据组成元数据打包单元,并写入元数据打包文件末尾;
S35遍历完成后,修改临时目录的属性为“打包目录”Archive,访问元数据服务器,使用临时目录替换原打包目录,即:将原打包目录删除,并将临时目录更名为原目录名;
S36等待预先设定的时间周期,转向步骤S31。
本发明的有益效果:本发明的分布式文件系统中海量小文件透明打包存储与访问的方法通过目录打包操作将小文件按照特定格式打包存储为少数几个大文件,降低元数据存储和服务压力,有效提升分布式文件系统可支持的文件数量;同时,小文件打包存储,极大减少了存储介质块内空间的浪费,同时可使得分布式文件系统采用较高存储效率的数据保护方式,从而有效提升存储空间利用率;再者,通过打包目录透明访问模块,可使上层应用透明地访问打包后的小文件目录,从应用角度打包目录与原目录的目录结构与访问方式均完全一致,应用无需为打包目录做任何改变即可适配;同时,考虑到数据访问的局部性特征,通过打包目录访问同属一个打包目录的多个小文件时,可在一定程度上提升小文件访问的性能;重打包模块还能对经过修改的打包文件进行再次整理,使得面向打包文件的数据读写效率得到优化。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的分布式文件系统架构图;
图2是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的目录打包模块打包流程图;
图3是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录结构及元数据/数据打包文件组成图;
图4是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录透明访问总流程图;
图5是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录透明访问示意图;
图6是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录元数据写操作流程图;
图7是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录元数据读操作流程图;
图8是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录数据写操作流程图;
图9是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的打包目录数据读操作流程图;
图10是根据本发明实施例所述的分布式文件系统中海量小文件透明打包存储与访问的方法的重打包操作流程图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本发明保护的范围。
为了方便理解本发明的上述技术方案,以下通过具体使用方式上对本发明的上述技术方案进行详细说明。
实施例1
在本实施例中,应用了本发明的分布式文件系统架构图如附图 1 所示,其中,分布式文件系统有四个基本组件:客户端、元数据服务器、数据服务器以及管理服务器,所有组件均部署于一套通过网络互联的服务器集群之上,一个集群存在多个物理服务器节点,通过分布式文件系统可以将多个物理服务器节点的存储资源整合为单一的存储资源池,通过网络可提供单一名字空间的文件服务。
其中:客户端部署于应用所在物理机器之上,通过操作系统的标准文件系统接口向应用提供标准文件访问。客户端通过与后端的元数据服务器和数据服务器通讯,完成上层应用发出的文件操作请求。元数据服务器和数据服务器分别管理文件系统中的元数据和数据,并响应来自客户端的访问请求。管理服务器负责整个分布式文件系统的系统管理功能,包括系统内软硬件组建的监控、管理以及数据管理。四个主要部件通过网络相互通讯和协作,向上层应用提供单一映象的网络文件服务。
在上述分布式文件系统架构和访问流程中增加了三个功能模块:目录打包模块、打包目录透明访问模块和重打包模块,三个模块相互协作,在现有分布式文件系统完整文件访问流程基础上实现面向小文件应用优化的透明打包存储与访问功能,提升分布式文件系统在海量小文件场景下的存储效率。
其中,目录打包模块作为一项数据管理的子功能被嵌入分布式文件系统的管理服务器之中,由管理服务器进行启动和管理,随管理服务器启动后在后台持续运行。其功能是遵循打包策略将整个普通目录内容打包成打包目录,打包目录内只有少量几个文件,按照特定格式存储了原普通目录的完整目录树及文件内容。目录打包模块目标是对普通目录打包以替换原有目录并删除,从而大幅降低系统内小文件数量。
打包目录透明访问模块则作为一项数据访问子功能嵌入分布式文件系统的客户端中,成为文件系统访问流程的一部分,接管所有面向打包目录的文件系统操作,并向用户返回操作结果,该模块的目标是在系统中存在打包目录的情况,保证向上层应用提供一致的文件访问接口,并且,上层目录访问打包后目录与访问原普通目录时的目录树和访问方式均完全一样,实现对上层应用完全透明。
重打包模块作为一项数据管理子功能嵌入分布式文件系统的管理服务器中,由管理服务器启动和管理,随管理服务器启动后,在后台持续运行,定期检查现有的打包目录,如某个打包目录在后续应用访问中进行了足够多的修改,满足重新打包的条件,则对该打包目录进行重打包操作,生成新的打包目录以替换原打包目录。重打包模块的目标是对打包目录进行存储优化,减少因为打包目录后期被更改而造成的存储冗余及访问开销,使系统访问打包目
录的读写操作更为高效。
在本实施例中,元数据服务器应可支持普通目录和打包目录两种目录类型,并作为目录的一个元数据属性存储,客户端通过请求目录元数据可获知目录类型,并依此选择是否由打包目录透明访问模块来接管后续该目录下的文件操作。
在本实施例中,上层应用根据业务需求自主地通过标准文件接口访问分布式文件系统,实施各种文件操作,由于客户端中提供对打包目录的透明访问模块,上层应用对所操作目录在分布式文件系统后端是普通目录还是打包目录并不知情。与此同时,目录打包模块和重打包模块在后台独立地周期运行,检查上层应用所写入的文件和目录,对满足条件的普通目录和打包目录进行打包或者重打包操作,以大幅降低分布式文件系统中文件数量,从根本上解决海量小文件的核心问题。由此可知,本发明所述方法在分布式文件系统中对应三个相对独立的子流程,即:目录打包流程、打包目录透明访问流程以及重打包流程。
参见附图 2,本图展示了本实例中的目录打包流程,其步骤如下:
步骤 1.1 进入一次目录打包操作周期;
步骤 1.2 加载打包策略,该策略说明了一个普通目录达到实施打包的条件,如目录名称规则、目录生成时间等,打包策略由系统管理员事先设定,并可按需更改;
步骤 1.3 对文件系统内所有普通目录进行遍历,将每个目录的属性与策略中的打包条件进行比对,满足条件的目录被筛选出来形成打包目录列表;
步骤 1.4 对目录列表中的目录逐个或者并发地进行打包操作,对于任意一个需要打包的普通目录,实施以下子步骤:
步骤 1.4.1 对应地创建一个临时目录,作为原普通目录打包后的数据暂存位置;
步骤 1.4.2 发起对原普通目录的遍历操作,读取目录内的所有子目录和文件的元数据和数据,分别处理后写入临时目录内,形成元数据打包文件和数据打包文件。
元数据打包文件记录了该目录内所有子目录和文件的元数据信息,数据打包文件整合存储了目录内所有文件数据。其中:
对于一个目录,直接将其元数据信息连同该目录所有目录项信息组成一个元数据打包单元,顺序写入元数据打包文件末尾。
对于一个文件,首先要将文件的数据顺序的写入到数据打包文件末尾,并记录写入时数据打包文件的初始偏移量(offset),然后将该文件的所有元数据读出,去掉其中原有的数据分布信息,替换成 offset,将新的文件元数据组成元数据打包单元,并写入元数据打包文件末尾。
元数据打包文件与数据打包文件的详细格式和组成可参见附图 3。
步骤 1.4.3 遍历完成后,修改临时目录的属性为“打包目录”(Archive);
步骤 1.4.4 访问元数据服务器,使用临时目录替换原目录,即:将原目录删除,并将临时目录更名为原目录名。
步骤 1.5 等待所有打包列表中普通目录打包完成,跳转至步骤 1.1,开始一个新的目录打包周期。
经过本实施例所述的目录打包流程,系统中元普通目录下的大量小文件,整合为少量几个元数据打包文件和数据打包文件,系统内文件数量大幅减少,在很多应用场景下,数据量的减少可能达到几个数量级。
同时,目录打包过程中,如打包数据量较大,所述的元数据打包文件和数据打包文件会等大小分割为多个按序号编号的多个子文件,以方便打包目录内的文件管理。
在本实施例中,在分布式文件系统的客户端集成打包目录的透明访问模块的的目的,是为上层应用提供使用原目录路径名访问打包后目录的透明访问能力。由上述目录打包流程可知,打包后,原目录内所有子目录和文件被删除,取而代之的是几个较大的元数据打包文件和数据打包文件,如不做特别处理,上层应用将直接访问这几个文件,原目录中的目录树及小文件则无法访问。透明访问模块的目标就是在上层应用访问该打包目录时,并不显示真实的元数据打包文件和数据打包文件,而是显示为打包前原目录的目录结构,并且可使用该目录结构访问其中文件,正常地完成相应读写操作,实现对打包目录的透明访问。为此,打包目录的透明访问模块中主要针对文件系统中元数据和数据的读写操作流程进行改变,包括四个方面:打包目录的元数据写操作流程、打包目录的元数据读操作流程、打包目录的数据写操作流程以及打包目录的读操作流程。
上层应用通过客户端对分布式文件系统的访问时,对特定文件或目录的操作需首先访问上层各级目录完成目标文件/目录的按名查找过程。因此,客户端在一级一级按名查找的过程中,通过检查各级目录类型,判断目录类型是否为 Archive,如果不是则使用常规的目录/文件访问流程进行处理,如果是打包目录(Archive)时,即将上层应用的文件访问请求转由打包目录透明访问模块进行处理,并根据操作类型和目标,决定具体处理的子流程。该步骤参见附图 4。
本实施例中,当上层应用发出的文件系统操作是面向一个打包目录时,无论具体操作类型如何,均需要首先将打包目录中的元数据打包文件一次性的加载至客户端缓存,以特定的数据结构保存,作为重建整个打包目录原目录树的基础,当上层应用以原目录路径名访问特定目录或文件时,还可被客户端正常解析。参见附图 5。图例中,上层应用要访问的文件在打包前文件路径名为/mnt/dayu/app/small/dir/file1,经打包后,打包目录/mnt/dayu/app 只有名为.dayu_archive_md.1 和.dayu_archive_data.1 这两个文件,并未有./small/dir/file1 这个文件,当 客 户 端 发 现 所 访 问 的 文 件 为 app 目录 下 文 件 , 而 app 类型为 Archive 时,加载.dayu_archive_md.1 到客户端缓存,重建打包目录 app 的目录树结构,首先查找 app 根目录元数据项(即打包目录的根),在其目录项中查找 small 目录,并在 small 的目录项中查找 dir,因此查找出 file1 的元数据单元,并其中获取 file1 的所有元数据信息,包括 Layout 信息,在打包文件中,文件的Layout 即为其在数据文件中的偏移量。
完成了打包目录元数据打包文件的加载,再根据操作的具体类型和目标选择不同的子流程进行处理。
其中,打包目录透明访问模块的元数据写操作的具体步骤如附图 6 所示。所谓元数据写操作包括创建/删除目录、创建/删除文件、改变属主/数组、权限修改、改变 Layout等所有可能修改对目录和文件的元数据信息进行修改的操作。具体步骤如下:
步骤 2.1 在打包目录内重建需要修改的目录或文件。所谓重建,是按照目标目录或文件原目录完整路径,在打包目录内创建整个完整路径,如要进行元数据修改的文件路径名为:/mnt/dayu/app/small/dir/file2,而当前/mnt/dayu/app 下只有元数据打包文件和数据打包文件,则需要创建 app 目录下的各级目录和文件:small/dir/file2。创建过程中,目标路径上所有目录及最底层的文件,如不存在并且不在其父目录的.deleted 目录中,则按照原目录/文件的属性依次新建。如果存在于其父目录的.deleted 目录中,说明该目录/文件已经被删除,则直接返回应用目标不存在。
重建中,目录重建不会包含其目录项,只有写操作涉及的目录项才会被创建;文件重建时,则该文件的所有数据要一并从数据打包文件对应位置读取,写入新建文件,完全复制该文件。重建的结果是目标目录或文件以普通目录/文件的形式存在于打包目录内,而且与元数据打包文件中的元数据属性完全一致。
步骤 2.2 如果上层应用的元数据写操作不是目录或者文件删除,则将该操作直接在重建的普通目录或者文件上执行,并返回操作结果。
步骤 2.3 如果上层应用的元数据写操作是目录或者文件删除,则通过访问缓存中被删除目录或文件的父目录,读取其目录项内容,判断被删除的目录/文件之前是否存在于原目录中,如果存在,则在删除时,将该目录/文件移动至其重建后的父目录下的特殊目录.deleted 中,重建目录下的.deleted 为系统保留目录,保存目录下被删除的打包目录项,在第一次对该目录发起删除时,自动创建。如果不存在,则直接删除对应重建目录和文件,并返回操作结果。
在本实施例中,打包目录透明访问模块的元数据读操作流程如附图 7 所示,由于打包目录中可能存在打包后应用对原目录和文件的修改,例如:目录/文件的删除和新增,因此在对打包目录访问时,应首先判断操作目标是否已经在打包目录内被重建,如果被重建了,则应返回其最新的元数据信息,即重建后的普通目录或文件的元数据信息,具体步骤如下:
步骤 3.1 判断操作的目标目录或文件是否已经被重建,如果未被重建,转到步骤3.2;如果已被重建,判断操作是否为获取目录的目录项,如果不是则直接读取重建目录或文件的元数据信息并返回;如果是,则首先获取缓存中原目录中的目录项内容,并将重建目录下.deleted目录中对应的目录项从中删除,然后再合并重建目录下当前的目录项,将最终结果返回上层应用。
以/mnt/dayu/app/small/dir 目录的readdir 操作为例,假如 dir 目录下原本有三个文件 file1,file2,file3 三个文件,后续对打包文件的进行写操作时,在 dir 目录下对 file2 进行了数据修改,删除了 file3,新建了 file4 文件,那么按照上述步骤,首先从缓存中读出所有目录项 file1,file2,file3,然后列举重建的 dir 的.deleted 目录中有 file3,将其删除,剩下的列表项为 file1, file2,再读取当前重建的 dir 下的目录项(不包括元数据打包文件、数据打包文件及.deleted目录,这些均为系统保留文件/目录)。最终返回给应用的列表为:file1,file2,file4。
步骤 3.2 检查其父目录是否已经被重建,如果其父目录未重建,转到步骤 3.3,如果已重建,在其重建父目录的.deleted 目录下查找目标目录或文件是否存在,如果不存在,转到步骤 3.3,如果存在,则返回上层应用,提示错误该目录/文件不存在。
步骤 3.3 在客户端缓存中直接查找目标目录或文件,并将缓存中对应的元数据信息返回。
在本实施例中,打包目录透明访问模块的数据写操作流程如附图 8 所示,文件数据的写操作与元数据写操作一样需要在写操作开始前,重建该文件,然后对重建后的文件进行操作。
具体步骤如下:
步骤 4.1 判断该文件是否已经在打包目录内被重建,如果已经被重建,转到步骤4.3,如果未重建,在打包目录内重建该文件,重建过程中,按照路径中的各级目录,逐级在打包目录内检查该级是否存在,如不存在且不在其父目录的.deleted 目录,则复制客户端缓存中对应目录的属性生成该级目录,直至最低一级目录;如果重建目录或文件存在于其父目录.deleted目录中,则直接返回上层应用,被访问的目录/文件不存在。创建目录时不包含其目录项。
步骤 4.2 从客户端缓存中依照原文件属性创建同名新文件,并将原文件的数据从数据打包文件对应位置读取,写入新建文件,重建原文件为打包目录下的普通文件。
步骤 4.3 对重建后的文件执行上层应用发起的数据写请求,并将结果返回。
以/mnt/dayu/app 打包目录为例,假如/mnt/dayu/app/small/dir 目录下原本有三个文件file1,file2,file3 三个文件,后续对打包文件的进行写操作时,在 dir 目录下对 file2 进行了数据修改,删除了 file3,新建了 file4 文件,那么后续对 dir 下文件进行写操作时,如果被操作文件为 file1,则需要首先重建 file1,再对 file1 进行操作,对 file2、file4 则直接进行操作,因为这两个文件已经被重建,对 file3 进行操作时,向上层应用返回错误:文件不存在。
在本实施例中,打包目录透明访问模块的数据读操作流程如附图 9 所示,由于打包目录中可能存在打包后应用对原目录和文件的修改,例如:文件的删除和新增,因此在对打包目录访问时,应首先判断被操作文件是否已经在打包目录内被重建。重建后的文件操作方式与普通文件无异,而未被重建的文件则则需在数据打包文件中读取数据内容,首先在打开文件时从客户端缓存中获取文件元数据信息,其中有文件的布局信息(Layout)和文件大小。不同于普通文件,打包目录中文件的布局信息(Layout)中保存的是该文件在数据打包文件中的起始位置(offset),透明访问模块以此位置为被访问文件的起始位置(即偏移量=0),按照读操作参数完成数据读操作,读操作中判断读取位置是否超过了被访问文件的大小,以免读取其它文件的数据。需要说明的是:数据打包文件可能会被拆分,但 offset统一编址,在数据读操作时,按照 offset 判断在某个拆分文件中的具体位置。
其步骤如下:
步骤 5.1 检查被操作文件是否已经被重建,如果未被重建,转到步骤 5.2;如果已被重建,直接对重建目录执行数据读操作,并返回结果。
步骤 5.2 检查其父目录是否已经被重建,如果其父目录未重建,转到步骤 7.3,如果已重建,在其重建父目录的.deleted 目录下查找目标文件是否存在,如果存在,则返回上层应用该目录/文件不存在。如果不存在,则转到步骤 5.3
步骤 5.3 在客户端缓存中直接查找目标文件元数据信息,获取文件的布局信息(Layout)和文件大小。在打包目录下的数据打包文件中,按照 Layout 信息,即偏移量,以及读操作的参数完成数据读操作,并返回结果。
同样以上述数据写操作流程中的/mnt/dayu/app/打包目录为例,经过对其中 dir目录修改后,再次对 dir 下的 file1、file2、file3 和 file4 发起数据读操作,则面向file1 的读操作直接从数据打包文件的对应 offset 位置读取,面向 file2、file4 的读操作直接以普通文件数据读方式进行,而面向 file3 的读操作则返回“文件不存在”错误给上层应用。
在本实施例中,重打包流程与目录打包流程基本一致,均通过管理服务器启动并持续运行,所不同的是,重打包流程检查所有的打包目录而不是普通目录,检查其重建目录/文件数量与原打包目录相比是否达到了某个预设比例,如果达到预设比例,则对该打包目录进行重打包操作,并且打包过程中,原目录数据的读取需要通过本发明所述的打包目录的透明访问流程。具体步骤如附图 10 所示:
步骤 6.1 对文件系统内所有已存在的打包目录进行检查,判断打包目录内重建目录和文件数量与原打包目录相比是否达到了预设比例。达到比例的目录组成重打包目录列表。如果列表为空,直接进入步骤 6.3。
预设比例由管理员设置,该比例被认为是打包目录因为重建目录/文件大量存在,导致数据访问效率降低的最大可容忍比例,超过比例,就需要将打包目录重新打包,消除大量存在的重建目录和文件。
步骤 6.2 对重打包目录列表中的所有目录,逐个或者并发的执行重打包操作。重打包操作与目录打包操作完全一致,不同的是该打包目录下所有元数据读取需要通过本实施例中步骤 3.1~步骤 3.3 所属流程,所有数据读取需要通过本实施例中步骤 5.1~步骤 5.3 所属步骤。
步骤 6.3 等待预先设定的时间周期,转向步骤 6.1。
目录打包流程的有益效果为:将原目录的大量文件,整合为元数据打包文件和数据打包文件,这两类文件均只有少量几个(元数据/数据量过大时,打包文件会做适当的等大小切割)。可以成几个数量级的减少系统内文件数量。整个目录打包为大文件存储可以有效的减少小文件存储时大量块内剩余空间所造成的空间浪费。尤其是在分布式存储系统中,以大文件存储,使得使用更高存储空间利用的数据保护方式成为可能,从而有效提升存储空间利用率。
打包目录透明访问流程的有益效果为:在将系统内的小文件进行打包操作后,还向上层应用提供与原目录完全一致的目录树结构和操作方式,无需应用程序针对打包目录做任何改动,从应用角度不会感知到目录是否被打包,在实现透明访问的前提下,通过目录打包的方式对小文件的存储和访问进行优化。
重打包流程的有益效果为:打包目录在后续的访问中,可能存在大量对原目录和文件的修改,这些修改以重建目录和文件的形式存在,相对于打包文件,访问路径更复杂,并且会导致文件数量增多,重打包操作对这种打包目录再次进行打包操作,消除原打包目录中的重建目录和文件,减少文件数量,提升打包目录的访问效率。
综上所述,借助于本发明的上述技术方案,通过目录打包操作将小文件按照特定格式打包存储为少数几个大文件,降低元数据存储和服务压力,有效提升分布式文件系统可支持的文件数量;同时,小文件打包存储,极大减少了存储介质块内空间的浪费,同时可使得分布式文件系统采用较高存储效率的数据保护方式,从而有效提升存储空间利用率;再者,通过打包目录透明访问模块,可使上层应用透明地访问打包后的小文件目录,从应用角度打包目录与原目录的目录结构与访问方式均完全一致,应用无需为打包目录做任何改变即可适配;同时,考虑到数据访问的局部性特征,通过打包目录访问同属一个打包目录的多个小文件时,可在一定程度上提升小文件访问的性能;重打包模块还能对经过修改的打包文件进行再次整理,使得面向打包文件的数据读写效率得到优化。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (3)
1.一种分布式文件系统中海量小文件透明打包存储与访问的方法,其特征在于,包括以下步骤:
S1目录打包流程:目录打包模块对分布式文件系统内存储小文件的普通目录进行后台打包操作,将该普通目录内所有文件和目录的元数据和数据整合存储为元数据打包文件和数据打包文件,生成打包目录,并替换该普通目录;
S2打包目录透明访问流程:打包目录透明访问模块嵌入分布式文件系统客户端的文件访问流程中,上层应用以原目录路径和访问方式访问打包目录时,由打包目录透明访问模块处理访问请求,将原目录请求映射为面向打包目录及其内所保存的元数据打包文件和数据打包文件的操作,并返回与原目录一致的操作结果;
S3重打包流程:重打包模块对分布式文件系统内打包文件进行重新打包,整合打包目录生成后所进行的文件和目录的修改,重新生成元数据打包文件和数据打包文件;
所述S2包括以下步骤:
S21判断该打包目录的元数据内容是否已经被加载至客户端缓存,如已加载,执行S22;
S22读取打包目录内的元数据打包文件,将所有文件和目录的元数据信息加载在客户端的缓存中,并采用特定数据结构重建整个打包目录的原目录树;
S23根据上层应用文件系统操作的目标和类型,选择执行:S231元数据写流程、S232元数据读流程、S233数据写流程以及S234数据读流程;
所述S23中S231元数据写流程包括以下步骤:
S2311根据元数据操作的目录或文件的路径名,在打包目录内重建该路 径,重建过程中,按照路径中的各级目录,逐级在打包目录内检查是否已经存在,如不存在并且不在其父目录的.deleted 目录中,则按照客户端缓存中对应目录的属性生成对应目录,直至最低一级目录,如果存在于其父目录的.deleted 目录中,则直接返回应用操作目标不存在,目录重建时不包含其目录项;
S2312如果重建的最低一级为文件,从客户端缓存中依照原文件属性创建同名新文件,并将原文件的数据从数据打包文件对应位置读取,写入新建文件,重建原文件为打包目录下的普通文件;
S2313被操作的目录和文件被重建后,如果元数据操作类型不是删除,则直接在重建目录和文件上进行操作,并将操作结果返回;
S2314如果元数据操作为目录或文件删除,判断被删除的目录/文件之前是否存在于打包目录对应原目录中,如果存在,则在删除时,将该目录/文件移动至其重建后的父目录下的特殊目录.deleted中,重建目录下的.deleted为系统保留目录,保存目录下被删除的打包目录项,如果不存在,则直接在重建目录和文件上进行操作,并返回操作结果;
所述S23中S232元数据读流程包括以下步骤:
S2321检查被操作目录和文件是否已经被重建为普通目录和文件,如果未被重建,转到S2322;如果已被重建,判断操作是否为获取目录的目录项,如果不是则直接读取重建目录或文件的元数据信息并返回;如果是,则首先获取缓存中原目录中的目录项内容,并将重建目录下.deleted 目录中对应的目录项从中删除,然后再合并重建目录下当前的目录项,将最终结果返回上层应用;
S2322检查其父目录是否已经被重建,如果其父目录未重建,转到S2323,如果已重建,在其重建父目录的.deleted 目录下查找目标目录或文件是否存在,如果不存在,转到S2323,如果存在,则返回上层应用,提示错误该目录/文件不存在;
S2323在客户端缓存中直接查找目标目录或文件,并将缓存中对应的元数据信息返回;
所述S23中S233数据写流程包括以下步骤:
S2331根据数据操作文件的路径名,判断该文件是否已经在打包目录内被重建,如果已经被重建,转到S2333,如果未重建,在打包目录内重建该文件,重建过程中,按照路径中的各级目录,逐级在打包目录内检查是否已经存在,如不存在,则按照客户端缓存中对应目录的属性生成对应目录,直至最低一级目录,如果重建目录或文件存在于其父目录.deleted目录中,则直接返回上层应用,被访问的目录/文件不存在,创建目录时不包含其目录项;
S2332从客户端缓存中依照原文件属性创建同名新文件,并将原文件的数据从数据打包文件对应位置读取,写入新建文件,重建原文件为打包目录下的普通文件;
S2333对重建后的文件执行上层应用发起的数据写请求,并将结果返回;
所述S23中S234数据读流程包括以下步骤:
S2341检查被操作文件是否已经被重建,如果未被重建,转到S2342,如果已被重建,直接对重建目录执行数据读操作,并返回结果;
S2342检查其父目录是否已经被重建,如果其父目录未重建,转到S2343,如果已重建,在其重建父目录的.deleted 目录下查找目标文件是否存在,如果存在,则返回上层应用该目录/文件不存在,如果不存在,则转到S2343;
S2343在客户端缓存中直接查找目标文件元数据信息,获取文件的布局信
息Layout和文件大小,在打包目录下的数据打包文件中,按照 Layout 信息以及读操作的参数完成数据读操作,并返回结果。
2.根据权利要求1所述的透明打包存储与访问的方法,其特征在于,所述S1包括以下步骤:
S11目录打包模块对分布式文件系统内所有相关目录进行遍历,并将目录的属性与打包策略中的打包条件进行比对,将满足条件的目录筛选出来形成打包目录列表,打包策略规定了目录满足打包的条件,由用户事先设定;
S12对打包目录列表中的所有目录,逐个或者并发的执行S13至S15,如果列表为空,直接进入S16;
S13针对一个普通目录开始打包,首先创建一个临时目录,作为原目录打包后的数据暂存位置;
S14发起对原目录的遍历操作,逐级对目录内的所有子目录和文件进行打包处理,在临时目录内生成元数据打包文件和数据打包文件,元数据打包文件记录了该目录内所有子目录和文件的元数据信息,数据打包文件整合存储了目录内所有文件数据,以下是遍历时对单个目录和文件的具体打包操作:对于一个目录,直接将其元数据信息连同该目录所有目录项信息组成一个元数据打包单元,并将该打包单元顺序写入元数据打包文件末尾;对于一个文件,首先要将文件的数据顺序的写入到数据打包文件末尾,并记录写入时的初始位置offset,然后将该文件的所有元数据读出,去掉其中原有的数据分布信息,替换成offset,将新的文件元数据组成元数据打包单元,并写入元数据打包文件末尾;
S15遍历完成后,修改临时目录的属性为“打包目录”Archive,访问元数据服务器,使用临时目录替换原目录,即:将原目录删除,并将临时目录更名为原目录名;
S16等待预先设定的时间周期,转向步骤S11。
3.根据权利要求1所述的透明打包存储与访问的方法,其特征在于,所述S3包括以下步骤:
S31 重打包模块对文件系统内所有打包目录进行检查,判断打包目录内重建目录和文件数量与原打包目录相比是否达到了预设比例,所有达到比例的目录组成重打包目录列表,如果列表为空,直接进入S36;
S32对重打包目录列表中的所有目录,逐个或者并发的执行S33至S35进行重打包操作;
S33创建一个临时目录,作为原目录打包后的数据暂存位置;
S34发起对原打包目录的遍历操作,该操作应用所述S2中元数据读流程与数据读流程,逐级对打包目录内的所有子目录和文件进行打包处理,在临时目录内生成元数据打包文件和数据打包文件,元数据打包文件记录了该目录内所有子目录和文件的元数据信息,数据打包文件整合存储了目录内所有文件数据,以下是遍历时对单个目录和文件的具体打包操作:对于一个目录,直接将其元数据信息连同该目录所有目录项信息组成一个元数据打包单元,并将该打包单元顺序写入元数据打包文件末尾;对于一个文件,首先要将文件的数据顺序的写入到数据打包文件末尾,并记录写入时的初始位置offset,然后将该文件的所有元数据读出,去掉其中原有的数据分布信息,替换成 offset,将新的文件元数据组成元数据打包单元,并写入元数据打包文件末尾;
S35遍历完成后,修改临时目录的属性为“打包目录”Archive,访问元数据服务器,使用临时目录替换原打包目录,即:将原打包目录删除,并将临时目录更名为原目录名;
S36等待预先设定的时间周期,转向步骤S31。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111367066.0A CN114048185B (zh) | 2021-11-18 | 2021-11-18 | 一种分布式文件系统中海量小文件透明打包存储与访问的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111367066.0A CN114048185B (zh) | 2021-11-18 | 2021-11-18 | 一种分布式文件系统中海量小文件透明打包存储与访问的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114048185A CN114048185A (zh) | 2022-02-15 |
CN114048185B true CN114048185B (zh) | 2022-09-02 |
Family
ID=80210247
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111367066.0A Active CN114048185B (zh) | 2021-11-18 | 2021-11-18 | 一种分布式文件系统中海量小文件透明打包存储与访问的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114048185B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115422121B (zh) * | 2022-07-25 | 2023-06-06 | 安芯网盾(北京)科技有限公司 | 利用inotify监控文件的方法、装置、电子设备和存储介质 |
CN115794749A (zh) * | 2023-01-30 | 2023-03-14 | 广州市刑事科学技术研究所 | 移动终端数据提取方法、装置、设备和存储介质 |
CN116069729B (zh) * | 2023-04-06 | 2023-06-27 | 深圳市微克科技有限公司 | 一种文档智能打包方法、系统及介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104731921A (zh) * | 2015-03-26 | 2015-06-24 | 江苏物联网研究发展中心 | Hadoop分布式文件系统针对日志型小文件的存储和处理方法 |
CN105577720A (zh) * | 2014-10-15 | 2016-05-11 | 中兴通讯股份有限公司 | 移动应用打包的方法及系统 |
CN106406765A (zh) * | 2016-09-22 | 2017-02-15 | 江苏赞奇科技股份有限公司 | 基于文件链接的异构分布式存储系统及其文件管理方法 |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4256075B2 (ja) * | 2001-01-09 | 2009-04-22 | 富士通株式会社 | ファイルシステム及び記憶領域の管理方法 |
US7062490B2 (en) * | 2001-03-26 | 2006-06-13 | Microsoft Corporation | Serverless distributed file system |
CN103020315B (zh) * | 2013-01-10 | 2015-08-19 | 中国人民解放军国防科学技术大学 | 一种基于主从分布式文件系统的海量小文件存储方法 |
CN103473337A (zh) * | 2013-09-22 | 2013-12-25 | 北京航空航天大学 | 一种分布式存储系统中处理面向海量目录和文件的方法 |
CN105138571B (zh) * | 2015-07-24 | 2019-12-24 | 四川长虹电器股份有限公司 | 分布式文件系统及其存储海量小文件的方法 |
CN105404652A (zh) * | 2015-10-29 | 2016-03-16 | 河海大学 | 一种基于hdfs的海量小文件处理方法 |
CN106874383B (zh) * | 2017-01-10 | 2019-12-20 | 清华大学 | 一种分布式文件系统元数据的解耦合分布方法 |
CN107045531A (zh) * | 2017-01-20 | 2017-08-15 | 郑州云海信息技术有限公司 | 一种优化hdfs小文件存取的系统及方法 |
CN106874457B (zh) * | 2017-02-14 | 2020-03-06 | 郑州云海信息技术有限公司 | 一种通过虚拟目录来提升元数据集群性能的方法 |
CN108319634B (zh) * | 2017-12-15 | 2021-08-06 | 深圳创新科技术有限公司 | 分布式文件系统的目录访问方法和装置 |
CN110196841B (zh) * | 2018-06-21 | 2023-12-05 | 腾讯科技(深圳)有限公司 | 文件的存储方法和装置、查询方法和装置及服务器 |
CN109240999A (zh) * | 2018-08-24 | 2019-01-18 | 浪潮电子信息产业股份有限公司 | 一种基于小文件的自动化聚合打包方法及系统 |
CN111475469B (zh) * | 2020-03-19 | 2021-12-14 | 中山大学 | Kubernetes用户态应用中基于虚拟文件系统的小文件存储优化系统 |
-
2021
- 2021-11-18 CN CN202111367066.0A patent/CN114048185B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105577720A (zh) * | 2014-10-15 | 2016-05-11 | 中兴通讯股份有限公司 | 移动应用打包的方法及系统 |
CN104731921A (zh) * | 2015-03-26 | 2015-06-24 | 江苏物联网研究发展中心 | Hadoop分布式文件系统针对日志型小文件的存储和处理方法 |
CN106406765A (zh) * | 2016-09-22 | 2017-02-15 | 江苏赞奇科技股份有限公司 | 基于文件链接的异构分布式存储系统及其文件管理方法 |
Non-Patent Citations (1)
Title |
---|
基于HBase的小文件高效存储方法;熊安萍等;《重庆邮电大学学报(自然科学版)》;20160215(第01期);第128-133页 * |
Also Published As
Publication number | Publication date |
---|---|
CN114048185A (zh) | 2022-02-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114048185B (zh) | 一种分布式文件系统中海量小文件透明打包存储与访问的方法 | |
CN104981802B (zh) | 针对对象存储器索引系统的内容类别 | |
EP3317805B1 (en) | A policy aware unified file system | |
US9020996B2 (en) | Synthetic view | |
US8548957B2 (en) | Method and system for recovering missing information at a computing device using a distributed virtual file system | |
US8818951B1 (en) | Distributed file system having separate data and metadata and providing a consistent snapshot thereof | |
US10852981B2 (en) | System for migrating virtual tape volumes between filesystems | |
CN107180092B (zh) | 一种文件系统的控制方法、装置及终端 | |
US9189493B2 (en) | Object file system | |
US20160283501A1 (en) | Posix-compatible file system, method of creating a file list and storage device | |
CN111881107B (zh) | 支持多文件系统挂载的分布式存储方法 | |
US20220083504A1 (en) | Managing snapshotting of a dataset using an ordered set of b+ trees | |
US8612717B2 (en) | Storage system | |
JP2006268456A (ja) | ファイル管理装置、ファイル管理方法、及びファイル管理プログラム | |
CN116955278A (zh) | 分布式文件系统快照的聚合访问方法、装置及计算机设备 | |
CN113448946B (zh) | 数据迁移方法及装置、电子设备 | |
CN113204520B (zh) | 一种基于分布式文件系统的遥感数据快速并发读写方法 | |
JP2005316708A (ja) | 階層記憶装置、その復旧方法、及び復旧プログラム | |
CN109697021A (zh) | 一种磁盘快照的数据处理方法及装置 | |
CN114201474A (zh) | 数据服务方法及装置 | |
US8180793B2 (en) | Access to data stored in a file system | |
CN117215477A (zh) | 数据对象存储方法、装置、计算机设备和存储介质 | |
Junping | Analysis of key technologies of distributed file system based on big data [J] | |
CN117873967A (zh) | 分布式文件系统的数据管理方法、装置、设备及存储介质 | |
CN115658619A (zh) | 进程的处理方法、装置、处理器及电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |