CN116226041A - 分布式文件系统中的文件读/写方法、装置和设备 - Google Patents
分布式文件系统中的文件读/写方法、装置和设备 Download PDFInfo
- Publication number
- CN116226041A CN116226041A CN202211657218.5A CN202211657218A CN116226041A CN 116226041 A CN116226041 A CN 116226041A CN 202211657218 A CN202211657218 A CN 202211657218A CN 116226041 A CN116226041 A CN 116226041A
- Authority
- CN
- China
- Prior art keywords
- snapshot
- read
- write
- client
- file
- 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.)
- Pending
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/13—File access structures, e.g. distributed indices
-
- 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/11—File system administration, e.g. details of archiving or snapshots
- G06F16/128—Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
-
- 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
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种分布式文件系统中的文件读/写方法、装置和设备,用于解决分布式系统中快照锁互斥竞争导致文件读/写性能较低的技术问题。本发明在未进行快照处理的情况下,普通读/写IO只需申请所读/写的文件的上一级目录的读/写锁,有效降低快照处理所涉及的目录下文件读/写的互斥锁竞争和IO时延,同时为了保证快照业务的可靠性,在快照配置处理流程中加入预检查precheck流程,通过预检查流程在确保没有拿非全路径的snaplock读/写锁的读/写请求的情况下,才开始执行快照处理。本发明能够在MDS中减少文件读写对快照锁的互斥竞争,提升分布式文件系统的文件读/写性能,并可保证快照配置的可靠性。
Description
技术领域
本发明涉及通信及云计算技术领域,尤其涉及一种分布式文件系统中的文件读/写方法、装置和设备。
背景技术
目前,很多厂商正逐步采用全闪存储,例如在存储子系统中使用通过非易失性内存主机控制器接口规范(Non Volatile Memory Express,NVMe)连接固态硬盘(SolidState Disk或Solid State Drive,SSD)或其他闪存介质代替传统硬盘(Hard Disk Drive,HDD)。所以,在全闪存储版本中,底层的磁盘不再是性能瓶颈,而且文件系统客户端从内核态cephfs转为用户态libcephfs,nfsd(基本的NFS守护进程)也从内核态nfsd转为用户态ganesha-nfsd,可以减少以往由于内核态的软件缺陷(bug)导致整个节点崩溃(crash)的问题,但是用户态的性能相比内核态会有所降低。
快照可以认为是数据再现的一个副本或者复制。对于文件系统来说,文件系统快照是文件系统的一个即时拷贝,它包含了文件系统在快照生成时刻所有的信息,本身也是一个完整可用的副本。一般通过集群管理页面可以进行快照配置,可对打快照的目录、快照名、过期时间等参数进行配置。
Ceph文件系统(Ceph file system,Cephfs)为了确保快照特性的可靠,在相关读/写输入/输出(Input/Output,IO)流程中都需要获取全路径分布式快照锁即snaplock的读锁,对快照配置相关流程都需要获取snaplock写锁。在当前的元数据服务(MetaDataService,MDS)多线程架构下,涉及snaplock状态机变化的流程都加互斥锁进行保护。在小文件覆盖写较多的应用场景下,MDS中相关互斥锁的竞争很大,导致IO流程时延变大,大部分线程处于空闲等待状态,对于性能影响很大。
发明内容
有鉴于此,本发明提供一种分布式文件系统中的文件读/写方法、装置和设备,用于解决分布式系统中快照锁互斥竞争导致文件读/写性能较低的技术问题。
基于本发明实施例的一方面,本发明提供一种分布式文件系统中的文件读/写方法,该方法包括:
在无快照客户端执行快照处理期间,对根目录下的文件读/写IO都只申请所读/写文件上一级目录的非全路径快照读/写锁;
在快照客户端执行快照处理期间,对根目录下的文件读/写IO都需申请全路径快照读/写锁;
在快照客户端执行快照处理之前,需等待所有获取非全路径快照读/写锁的读/写IO都处理完成后,再开始执行快照处理。
进一步地,所述文件读/写IO通过快照锁定标记(snaplocking)来获知当前是否在进行快照处理;所述快照锁定标记(snaplocking)由所述快照客户端在执行快照处理前设置为真(true),在执行完快照处理后设置为假(false),所述快照锁定标记(snaplocking)为全局变量。
进一步地,所述文件读/写IO通过非快照请求计数(nosnapreq)来告知当前有申请到非全路径快照读/写锁的读/写IO在执行,所述非快照请求计数(nosnapreq)为全局变量;
所述文件读/写IO在申请成功非全路径快照读/写锁后将非快照请求计数(nosnapreq)加一,在释放非全路径快照读/写锁后将非快照请求计数(nosnapreq)减一。
进一步地,所述等待所有获取非全路径快照读/写锁的读/写IO都处理完成后,再开始执行快照处理步骤的方法为:
所述快照客户端在执行快照准备(do_prepare)前通过发起预检查(precheck)流程来设置快照锁定标记(snaplocking)来通知文件读/写IO当前在进行快照处理,并通过非快照请求计数(nosnapreq)等待当前申请到非全路径快照读/写锁的读/写IO执行完毕。
进一步地,所述预检查(precheck)流程包括:
所述快照客户端(snapclient1)在执行快照准备(do_prepare)前发起预检查(precheck)流程,所述预检查流程包括:
所述快照客户端(snapclient1)通知快照服务端(snapserver)发起预检查步骤;
所述快照服务端通知分布式文件系统中的所有快照客户端(snapclient1、snapclient2)执行预检查;
所述快照客户端(snapclient1、snapclient2)在接收到执行预检查的通知后,更新快照锁定标记(snaplocking)为真(true);
所述快照客户端(snapclient1、snapclient2)循环检查非快照请求计数(nosnapreq)是否为0,在判定非快照请求计数(nosnapreq)为0时,向快照服务端反馈预检查响应;
当快照服务端接收到所有快照客户端的预检查响应时,通知发起预检查步骤的快照客户端(snapclient1)执行快照准备(do_prepare)步骤。
进一步地,所述方法还包括:
所述快照客户端(snapclient1)在收到快照服务端发送的重置快照标签的通知(TABLECLIENT_OP_RESETSNAP)后,更新快照锁定标记(snaplocking)为假(false),以通知文件读/写IO快照处理流程执行完毕。
基于本发明实施例的另一方面,本发明还提供一种分布式文件系统中的文件读/写装置,该装置包括:
第一锁请求模块,用于在无快照客户端执行快照处理期间,对根目录下的文件读/写IO都只申请所读/写文件上一级目录的非全路径快照读/写锁;
第二锁请求模块,用于在快照客户端执行快照处理期间,对根目录下的文件读/写IO都需申请全路径快照读/写锁。
基于本发明实施例的另一方面,本发明还提供一种分布式文件系统中的快照处理装置,该装置应用于所述快照客户端。该装置可以软件、硬件或软硬结合的方式实现。当以软件模块方式实现时,当该软件模块的程序代码被加载到设备的存储介质中,由处理器读取存储介质中的程序代码进行执行,从而实现该装置中各组成模块的功能。该装置包括:
预检查模块,用于所述快照客户端在执行快照准备(do_prepare)前通过发起预检查(precheck)流程来设置快照锁定标记(snaplocking)来通知文件读/写IO当前在进行快照处理,并通过非快照请求计数(nosnapreq)等待当前申请到非全路径快照读/写锁的读/写IO执行完毕;
全局标记更新模块,用于所述快照客户端(snapclient1)在收到快照服务端发送的重置快照标签的通知(TABLECLIENT_OP_RESETSNAP)后,更新快照锁定标记(snaplocking)为假(false),以通知文件读/写IO快照处理流程执行完毕。
需要说明的是,本发明的方法可以由单个设备执行,例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下,由多台设备相互配合来完成。在这种分布式场景的情况下,多台设备中的一台设备可以只执行本发明的方法中的某一个或多个步骤,多台设备相互之间会进行交互以共同完成所述的方法实现本发明的发明目的,多台设备之间相互之间构成相互的指挥和控制关系。
附图说明
为了更加清楚地说明本发明实施例或者现有技术中的技术方案,下面将对本发明实施例或者现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据本发明实施例的这些附图获得其他的附图。
图1为本发明一实施例提供的一种分布式文件系统中的文件读/写方法的步骤流程示意图;
图2为本发明一实施例中分布式文件系统执行快照处理的流程示意图;
图3为本发明一实施例提供的用于实现本发明提供的分布式文件系统中的文件读/写方法的电子设备结构示意图。
具体实施方式
在本发明实施例使用的术语仅仅是出于描述特定实施例的目的,而非限制本发明实施例。本发明实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其它含义。应当理解,尽管在本发明实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用于区别类似的信息、实体或步骤,而不是用于描述特定的顺序或先后次序。例如,在不脱离本发明实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。此外,所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。本发明中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况,其中A,B可以是单数或者复数。并且,在本发明的描述中,除非另有说明,“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中a,b,c可以是单个,也可以是多个。
为保持快照特性的可靠性,传统读写IO和快照配置流程都需要获取全流程的snaplock读写锁,导致元数据服务MDS中相关互斥锁竞争增加,引起输入/输出即IO时延增大,从而影响业务性能。
本发明在采用全闪存的分布式存储系统中,针对文件系统,对核心的元数据服务(MetaData Service,MDS)和用户态客户端(libcephfs)文件覆盖写流程进行优化,针对用户态环境下,对写权限和快照锁机制做了改进,目的是提高普通读写IO的性能,同时保证快照配置(包括快照的生成和配置)的安全,本发明技术方案不区分快照类型,适用于所有类型的快照。
本发明的核心思想是,在未进行快照处理的情况下,普通读/写IO不再申请全路径的snaplock读写锁,只需申请所读/写的文件的上一级目录的读/写锁,这将有效降低快照处理所涉及的目录下文件读/写的互斥锁竞争和io时延,同时为了保证快照业务的可靠性,在快照配置处理流程中加入预检查precheck流程,通过预检查流程在确保没有拿非全路径的snaplock读/写锁的读/写请求的情况下,才开始执行快照处理。本发明技术方案能够在MDS中减少文件读写对快照锁的互斥竞争,从而提升分布式文件系统的文件读/写性能,尤其是提升小文件的读/写性能,并可保证快照配置的可靠性。
基于本发明的基本思想,以下结合附图和具体实施例来描述本发明的具体实现过程。
本发明提出的技术方案对分布式文件系统的快照锁机制进行了优化,优化包括对文件读/写流程的优化和对快照处理流程的优化两个部分。实际上也可以将本发明看作是对分布式文件系统的文件读/写流程的优化,因为本发明的主要发明目的是为了提升分布式文件系统的文件读/写性能,对快照处理流程的优化是服务于该发明目的的。以下首先对文件读/写流程的优化进行详细描述。
通过分析和梳理性能影响因素和集群主要的使用场景后,发现普通读/写IO的使用场景和使用规模,远大于快照配置业务,所述的普通读/写IO是指对文件内容进行正常业务读/写的IO,普通读/写IO不涉及快照处理、系统配置等操作。而现有方案中,不论普通读/写IO还是快照处理(包括快照配置、创建、删除等与快照相关的操作),都需要获取全目录的读/写锁。为优化性能,本发明对于普通读/写IO流程,将不再获取全路径的读/写锁。
例如在现有方案中,假设在根目录“/”下有文件file1和文件file2,对于文件file1的路径:/data/dir1/dir2/file1,若要读取文件file1,则需要获取到根目录的整个路径的全路径读锁,若此时要读取文件file2:/data/dir1/dir3/file2,只能等file1读取后,释放全路径读锁,才可以继续读取file2。该流程严重影响普通IO性能。为了提升文件读/写性能,本发明中,在不予快照处理冲突的情况下,文件读/写IO仅需申请非全路径快照读/写锁,所以,在上面的例子中,本发明对于普通IO流程,在对file1和file2读/写时,只需要分别获取文件上一级目录dir2和dir3的非全路径快照读/写锁即可,无需申请全路径快照读/写锁。
图1为本发明一实施例提供的一种分布式文件系统中的文件读/写方法的步骤流程示意图。该方法包括:
步骤101.在无快照客户端执行快照处理期间,对根目录下的文件读/写IO都只申请所读/写文件上一级目录的非全路径快照读/写锁;
快照客户端snapclient是指提供元数据服务的元数据服务MDS节点,在一个分布式文件系统中,可能会有多个MDS节点提供元数据服务。在执行快照处理(例如生成快照、进行快照配置等)过程中,每个MDS节点即为一个快照客户端snapclient,快照客户端snapclient在快照服务端snapserver的控制下执行快照处理流程。
所述根目录可以是指分布式文件系统的整个文件系统的根目录,也可以是指配置执行快照处理的目标目录。所述针对根目录下的文件的读/写IO是指针对根目录下任意一个文件,包括根目录下的子目录以及子目录下的子目录中的任意一文件的读/写IO操作。
本发明中的全路径快照读/写锁是指施加生效于整个根目录的全目录快照读/写锁。非全路径快照读/写锁是指仅指施加生效于所读/写的文件所在上一级目录的快照读/写锁。两种锁的作用范围不同。非全路径快照读/写锁仅在未进行快照处理的时候使用,以减小锁的互斥,提升文件读/写性能。
步骤102.在快照客户端执行快照处理期间,对根目录下的文件读/写IO都需申请全路径快照读/写锁;
为了防止快照客户端在对目录执行快照处理时,有其它文件读/写IO通过获取非全路径快照读/写锁对目录中的文件进行读/写从而产生冲突,本发明通过一定的机制来使得分布式文件系统在快照处理期间只有获取到全路径快照读/写锁的情况下才能进行普通的文件读/写IO操作。
步骤103.在快照客户端执行快照处理之前,需等待所有获取非全路径快照读/写锁的读/写IO都处理完成后,再开始执行快照处理。
在本发明一实施例中,由快照客户端在快照处理流程中设置一个全局变量snaplocking来告知文件读/写IO当前是否正在进行快照处理。snaplocking可以为布尔值,默认为false,表示没有进行快照处理,true则表示在进行快照处理。当快照客户端开始执行快照处理流程时,将快照锁定标记snaplocking置为true,当执行完快照处理流程时,将snaplocking置为false。
快照客户端在执行快照处理流程时,为了避免普通读/写IO与快照处理流程的冲突,需等待获取到非全路径快照读/写锁的读/写IO执行完成后才能够开始执行快照处理流程,本发明一实施例中,通过提供一个全局变量(nosnapreq)来进行普通读/写IO的计数,在读/写IO请求锁(acquire_lock)流程完成之后,将非快照请求计数(nosnapreq)加一,待IO请求完成后,进行释放锁(drop_locks)流程,锁释放后将nosnapreq计数减一。全局nosnapreq计数可用来判断在执行快照处理前,是否有未拿全路径快照读/写锁的请求在执行即是否有获取非全路径快照读/写锁的读/写IO在执行,如果有,则nosnapreq会大于0,快照处理需要等到所有的读/写IO请求完成后,nosnapreq置为0时才能开始打快照,防止快照过程中数据被更改。
图2为本发明一实施例中分布式文件系统执行快照处理的流程示意图。若IO流程不再拿全目录的snaplock读/写锁,会导致快照不可靠。为保证快照特性的可靠,本发明对快照处理流程进行了优化。
在传统的快照处理流程中,收到创建快照请求(即mksnap请求)后,客户端进行请求锁操作,快照客户端snapclient处理prepare_create请求。准备prepare阶段为snapclient向快照服务端snapserver发送TABLESEVER_OP_PREPARE请求,snapserver端进行handle_prepare处理,即分配snapid、记录log等操作。后续snapserver端发送snapid等信息给client端进行mksnap请求创建快照。
本发明中,在快照处理流程的prepare准备检查阶段加入precheck预检查流程,如图2中precheck流程的框图内容。
1)snapclient端发送precheck请求即TABLESERVER_OP_PRECHECK到snapserver端,然后snapserver端将precheck通知给所有MDS节点即图中由snapserver发送给snapclient1和snapclient2的TABLESERVER_OP_PRECHECK。
2)Snapclient收到precheck通知后,进行全局变量nosnapreq的计数校验,并设置snaplocking标签为true(即表示在进行快照处理业务),使得后续请求都拿全路径的快照读/写锁。待nosnapreq计数为零时(即此时普通IO已释放读锁,全局计数为0,若全局nosnapreq计数非0,则继续重试,直到计数为零,则进行下一步),返回precheck请求响应即TBLECLIENT_OP_PRECHECKACK给snapserver端。
3)快照客户端snapclient完成precheck后,snapclient向snapserver端发送预检查响应TBLECLIENT_OP_PRECHECKACK消息,snapserver端进行hadle_precheckack处理,即问各snapclient端有没有都完成precheck。待所有客户端都回复TBLECLIENT_OP_PRECHECKACK后,snapserver进行后续操作,即判断是否所有的客户端都回复了,snapserver收到一个回复,会删除一个对应的rank,所有的客户端都回复后,gather size变为0,则完成预检查。snapserver回复snapclient端TABLESERVER_OP_PRECHECKACK(即表示预检查已完成),快照配置流程继续按照原有流程进行。
4)在快照处理流程回调函数中,快照处理事务提交commit的同时snapserver端给对应的snapclient发送resetsnap请求(即重置快照标签的请求),snapclient端重置snaplocking标签,即标记为false,表示快照处理已结束,后续若有普通读/写IO流程,则按照本发明优化的普通IO流程设计进行。该部分对应图2中的TABLECLIENT_OP_RESETSNAP流程。
本发明技术方案带来的有益效果
1、用户态环境下,普通读/写IO流程不再拿全目录的snaplock读/写锁,在MDS多线程架构下,减少了snaplock状态机变化而导致的相关互斥锁的竞争,降低io流程时延,有效提升了文件读写性能。
2、本发明通过增加snaplocking、nosnapreq标签和precheck流程,在提升业务性能的同时保证快照配置的可靠性。
图3为本发明一实施例提供的用于实现本发明提供的分布式文件系统中的文件读/写方法的电子设备结构示意图,该设备300包括:诸如中央处理单元(CPU)的处理器310、通信总线320、通信接口340以及存储器330。其中,处理器310与存储器330可以通过通信总线320相互通信。存储器330内存储有计算机程序,当该计算机程序被处理器310执行时即可实现本发明提供的分布式文件系统中的文件读/写方法中的一个或多个步骤的功能。
存储器是指基于某种存储介质用于存储计算机程序和/或数据的装置,它可以是易失性存储器(Volatile Memory,VM,常称为内存),也可以是非易失性存储器(Non-Volatile Memory,NVM)。内存是指与处理器直接交换数据的内部存储器,它可以随时读写数据,而且速度很快,作为操作系统和其它运行程序的临时数据的存储介质。内存可以是同步动态随机存取内存(Synchronous Dynamic Random Access Memory,SDRAM)、动态随机存取内存(Dynamic Random Access Memory,DRAM)等。非易失性存储器是指采用持久化存储介质的存储器,具有容量大和可持久保存数据的特性,可以是存储级存储器(StorageClass Memory,SCM)、固态硬盘(Solid State Disk,SSD)、NAND闪存、磁盘等。SCM是业界对介于内存与闪存之间的新存储介质的统称,是一种同时结合持久化存储特性与内存特性的复合型储存技术,存取速度慢于DRAM快于SSD硬盘。
处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
应当认识到,本发明的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性(或称为非持久性)存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术,包括配置有计算机程序的非暂时性存储介质在计算机程序中实现,其中如此配置的存储介质使得计算机以特定和预定义的方式操作。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而,若需要,该程序可以以汇编或机器语言实现。在任何情况下,该语言可以是编译或解释的语言。此外,为此目的该程序能够在编程的专用集成电路上运行。此外,可按任何合适的顺序来执行本发明描述的过程的操作,除非本发明另外指示或以其他方式明显地与上下文矛盾。本发明描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行,并且可作为共同地在一个或多个处理器上执行的代码(例如,可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。
进一步,所述方法可以在可操作地连接至合适的任何类型的计算平台中实现,包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本发明的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现,无论是可移动的还是集成至计算平台,如硬盘、光学读取和/或写入存储介质、RAM、ROM等,使得其可由可编程计算机读取,当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外,机器可读代码,或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时,本发明所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本发明所述的方法和技术编程时,本发明还包括计算机本身。
以上所述仅为本发明的实施例而已,并不用于限制本发明。对于本领域技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种分布式文件系统中的文件读/写方法,其特征在于,方法包括:
在无快照客户端执行快照处理期间,对根目录下的文件读/写IO都只申请所读/写文件上一级目录的非全路径快照读/写锁;
在快照客户端执行快照处理期间,对根目录下的文件读/写IO都需申请全路径快照读/写锁;
在快照客户端执行快照处理之前,需等待所有获取非全路径快照读/写锁的读/写IO都处理完成后,再开始执行快照处理。
2.根据权利要求1所述的方法,其特征在于,
所述文件读/写IO通过快照锁定标记来获知当前是否在进行快照处理;所述快照锁定标记由所述快照客户端在执行快照处理前设置为真,在执行完快照处理后设置为假,所述快照锁定标记为全局变量。
3.根据权利要求1所述的方法,其特征在于,
所述文件读/写IO通过非快照请求计数来告知当前有申请到非全路径快照读/写锁的读/写IO在执行,所述非快照请求计数为全局变量;
所述文件读/写IO在申请成功非全路径快照读/写锁后将非快照请求计数加一,在释放非全路径快照读/写锁后将非快照请求计数减一。
4.根据权利要求1所述的方法,其特征在于,所述等待所有获取非全路径快照读/写锁的读/写IO都处理完成后,再开始执行快照处理步骤的方法为:
所述快照客户端在执行快照准备前,通过发起预检查流程来设置快照锁定标记以通知文件读/写IO当前在进行快照处理,并通过非快照请求计数等待当前申请到非全路径快照读/写锁的读/写IO执行完毕。
5.根据权利要求4所述的方法,其特征在于,所述预检查流程包括:
所述快照客户端在执行快照准备前发起预检查流程,所述预检查流程包括:
所述快照客户端通知快照服务端发起预检查步骤;
所述快照服务端通知分布式文件系统中的所有快照客户端执行预检查;
所述快照客户端在接收到执行预检查的通知后,更新快照锁定标记为真;
所述快照客户端循环检查非快照请求计数是否为0,在判定非快照请求计数为0时,向快照服务端反馈预检查响应;
当快照服务端接收到所有快照客户端的预检查响应时,通知发起预检查步骤的快照客户端执行快照准备步骤。
6.根据权利要求4所述的方法,其特征在于,所述方法还包括:
所述快照客户端在收到快照服务端发送的重置快照标签的通知后,更新快照锁定标记为假,以通知文件读/写IO快照处理流程执行完毕。
7.一种分布式文件系统中的文件读/写装置,其特征在于,该装置包括:
第一锁请求模块,用于在无快照客户端执行快照处理期间,对根目录下的文件读/写IO都只申请所读/写文件上一级目录的非全路径快照读/写锁;
第二锁请求模块,用于在快照客户端执行快照处理期间,对根目录下的文件读/写IO都需申请全路径快照读/写锁。
8.一种分布式文件系统中的快照处理装置,其特征在于,该装置应用于所述快照客户端,该装置包括:
预检查模块,用于所述快照客户端在执行快照准备前通过发起预检查流程来设置快照锁定标记以通知文件读/写IO当前在进行快照处理,并通过非快照请求计数等待当前申请到非全路径快照读/写锁的读/写IO执行完毕;
全局标记更新模块,用于所述快照客户端在收到快照服务端发送的重置快照标签的通知后,更新快照锁定标记为假,以通知文件读/写IO快照处理流程执行完毕。
9.一种电子设备,其特征在于,包括处理器、通信接口、存储介质和通信总线,其中,处理器、通信接口、存储介质通过通信总线完成相互间的通信;
存储介质,用于存放计算机程序;
处理器,用于执行存储介质上所存放的计算机程序时,实施权利要求1-6中任一项所述的方法步骤。
10.一种存储介质,其上存储有计算机程序,其特征在于,所述计算机程序当被处理器执行时实施如权利要求1至6中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211657218.5A CN116226041A (zh) | 2022-12-22 | 2022-12-22 | 分布式文件系统中的文件读/写方法、装置和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211657218.5A CN116226041A (zh) | 2022-12-22 | 2022-12-22 | 分布式文件系统中的文件读/写方法、装置和设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116226041A true CN116226041A (zh) | 2023-06-06 |
Family
ID=86572116
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211657218.5A Pending CN116226041A (zh) | 2022-12-22 | 2022-12-22 | 分布式文件系统中的文件读/写方法、装置和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116226041A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116931845A (zh) * | 2023-09-18 | 2023-10-24 | 新华三信息技术有限公司 | 一种数据布局方法、装置及电子设备 |
-
2022
- 2022-12-22 CN CN202211657218.5A patent/CN116226041A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116931845A (zh) * | 2023-09-18 | 2023-10-24 | 新华三信息技术有限公司 | 一种数据布局方法、装置及电子设备 |
CN116931845B (zh) * | 2023-09-18 | 2023-12-12 | 新华三信息技术有限公司 | 一种数据布局方法、装置及电子设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11775485B2 (en) | Concurrent access and transactions in a distributed file system | |
US11687494B2 (en) | Concurrent access and transactions in a distributed file system | |
US11775500B2 (en) | File system consistency in a distributed system using version vectors | |
US11086726B2 (en) | User-based recovery point objectives for disaster recovery | |
CN109783578B (zh) | 数据读取方法、装置、电子设备以及存储介质 | |
JP2009251853A (ja) | メモリデータベース、メモリデータベースシステム及びメモリデータベース更新方法 | |
US11734122B2 (en) | Backup task processing in a data storage system | |
US7761424B2 (en) | Recording notations per file of changed blocks coherent with a draining agent | |
CN115408411A (zh) | 数据写入方法、装置、电子设备及存储介质 | |
CN116226041A (zh) | 分布式文件系统中的文件读/写方法、装置和设备 | |
US10592530B2 (en) | System and method for managing transactions for multiple data store nodes without a central log | |
US11132351B2 (en) | Executing transactions based on success or failure of the transactions | |
US20100191708A1 (en) | Synchronous Deletion of Managed Files | |
CN118296191A (zh) | 一种元数据管理方法及相关系统 | |
US20220255826A1 (en) | Reducing the impact of network latency during a restore operation | |
US11531644B2 (en) | Fractional consistent global snapshots of a distributed namespace | |
US11650961B2 (en) | Managing replica unavailability in a distributed file system | |
CN113190332B (zh) | 用于处理元数据的方法、设备和计算机程序产品 | |
US20230069165A1 (en) | Byzantine fault tolerant pre-preprocessing for state machine replication | |
CN112783436A (zh) | 用于信息生命周期管理的同步对象放置 | |
CN112306956A (zh) | 用于元数据维护的方法、装置和计算机程序产品 | |
WO2016120988A1 (ja) | データベースシステム及びデータベース管理方法 | |
CN118093104A (zh) | 一种任务处理方法、装置及节点 | |
CN117193662A (zh) | 快照卷的io处理方法、系统、终端及存储介质 | |
CN116186033A (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 |