掌桥专利:专业的专利平台
掌桥专利
首页

文件系统加锁方法、装置、设备及存储介质

文献发布时间:2024-04-18 20:02:18


文件系统加锁方法、装置、设备及存储介质

技术领域

本申请涉及分布式文件系统领域,尤其涉及一种文件系统加锁方法、装置、设备及存储介质。

背景技术

随着互联网和大数据的快速发展,数据量呈指数级增长。传统的单机文件系统无法满足巨大数据量的储存需求,因而需要采用分布式的文件系统来存储和管理数据。分布式的文件系统能够向用户提供分布式对象、文件、块存储服务,用于大数据和云计算领域。分布式文件系统可以向用户提供并发访问功能,通过多线程的方式来处理用户的请求,并且内部通过全局锁的方式来控制多线程访问,进而允许用户像操作本地文件系统一样使用分布式文件系统。

通过全局锁来控制多线程访问虽然保证了数据的一致性,但是也由于全局锁的存在导致单个线程持有锁的时间较长,进而导致多线程的并发处理能力不能充分得到利用,尤其是在多用户大压力访问的情况下,分布式文件系统不能充分并发处理请求。

因此,当前亟需要一种方法能够提高文件系统的并发处理能力。

发明内容

本申请提供一种文件系统加锁方法、装置、设备及存储介质,用以解决文件系统并发处理能力较低的技术问题。

第一方面,本申请提供一种文件系统加锁方法,包括:

获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识;

根据所述待访问文件的标识,获取访问同一目标文件的至少两个目标线程;

根据所述至少两个目标线程各自的访问类型,在不同的时间对所述目标文件进行加锁,以使得至少两个目标线程的请求阶段并发执行,数据访问阶段针对所述目标文件的同一数据域读写互斥。

在一种可能的设计中,所述根据所述至少两个目标线程各自的访问类型,在不同的时间对所述目标文件进行加锁,包括:

若所述至少两个目标线程的访问类型包括写请求类型和getattr访问类型,则在所述写请求类型对应的第一目标线程对目标文件进行请求处理时对所述目标文件加全局锁,并控制所述getattr访问类型对应的第二目标线程执行请求阶段,其中,所述第二目标线程的请求阶段与所述请求处理并行执行,所述请求处理包括请求阶段和数据访问阶段。

在一种可能的设计中,所述控制所述getattr访问类型对应的第二目标线程执行请求阶段,包括:

对所述客户端进行身份验证,以执行所述请求阶段;

所述控制所述getattr访问类型对应的第二目标线程执行请求阶段之后,所述方法还包括:

在身份验证通过后,在所述目标文件解锁后,对缓存的元数据加读锁,获取对所述元数据进行缓存的历史时间戳以及当前时间戳;

根据所述当前时间戳与所述历史时间戳获取所述元数据的生命时长;

若根据所述生命时长确定所述元数据未过期,则从所述元数据中读取所述访问请求对应的目标数据并返回;

若根据所述生命时长确定所述元数据已过期,则向MDS元数据服务器发送请求,并对所述元数据加写锁,通过写锁将请求得到的元数据更新至缓存中。

在一种可能的设计中,所述根据所述至少两个目标线程各自的访问类型,在不同的时间对所述目标文件进行加锁,包括:

若所述至少两个目标线程的访问类型均为写请求类型,则所述至少两个目标线程的请求阶段并发执行;

根据所述至少两个目标线程各自对应的写请求的目标文件的数据域,对所述至少两个目标线程写请求的数据域加作用域锁以进行写操作,以使得不同目标线程对同一数据域的写请求互斥。

在一种可能的设计中,所述根据所述至少两个目标线程各自对应的写请求的目标文件的数据域,对所述至少两个目标线程写请求的数据域加作用域锁,以使得不同目标线程对同一数据域的写请求互斥,包括:

根据所述至少两个目标线程各自对应的写请求的目标文件的数据域,在同一时间段,对至少两个目标线程的不同数据域分别并发加作用域锁以进行写操作,在不同数据域写操作完毕后,对各数据域进行解锁;

在下一时间段,对至少两个目标线程的其它不同数据域分别并发加作用锁以进行写操作,并在其它不同数据域写操作完毕后,对各数据域进行解锁,重复执行上述加锁和解锁操作,直至每个目标线程完成写操作。

在一种可能的设计中,所述根据所述至少两个目标线程各自的访问类型,在不同的时间对所述目标文件进行加锁,包括:

若所述至少两个目标线程的访问类型均为getattr访问类型,则所述至少两个目标线程对应的请求阶段并发执行;

在至少两个目标线程缓存的元数据均已过期时,并发对所述元数据加读锁,向MDS元数据服务器发送请求,并对所述元数据加写锁,通过写锁将请求得到的元数据更新至缓存中,所述至少两个目标线程的写请求互斥。

在一种可能的设计中,所述写请求类型的访问请求为创建目录mkdir的请求。

第二方面,本申请提供一种文件系统加锁装置,包括:

接收模块,用于获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识;

获取模块,用于根据所述待访问文件的标识,获取访问同一目标文件的至少两个目标线程;

锁模块,用于根据所述至少两个目标线程各自的访问类型,在不同的时间对所述目标文件进行加锁,以使得至少两个目标线程的请求阶段并发执行,数据访问阶段针对所述目标文件的同一数据域读写互斥。

第三方面,本申请提供一种文件系统加锁设备,包括:处理器,以及与所述处理器通信连接的存储器;

所述存储器存储计算机执行指令;

所述处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的文件系统加锁方法。

第四方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上第一方面以及第一方面各种可能的设计所述的文件系统加锁方法。

本申请提供的一种文件系统加锁方法、装置、设备及存储介质,通过获取客户端发送的多线程访问请求,根据每个访问请求中携带待访问文件的标识获取访问同一目标文件的至少两个目标线程。通过将每个目标线程分为请求阶段和数据访问阶段,从而使得至少两个目标线程的请求阶段能够并发执行,进而能够在至少两个目标线程在不同的时间段对目标文件进行加锁时,先并行处理至少两个目标线程的请求阶段,再对目标文件的同一数据域读写互斥,提高了文件系统的并发处理能力,避免多个目标线程对同一目标文件进行处理时,每个请求对目标文件的锁定时间过长导致的文件系统并发处理能力低的问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。

图1为本申请实施例的系统架构图;

图2为本申请实施例提供的文件系统加锁方法流程图一;

图3为本申请实施例提供的文件系统加锁方法流程图二;

图4A为本申请实施例提供的一种文件系统加锁方式示意图一;

图4B为本申请实施例提供的一种文件系统加锁方式示意图二;

图5为本申请实施例提供的文件系统加锁方法流程图三;

图6A为本申请实施例提供的一种文件系统加锁方式示意图三;

图6B为本申请实施例提供的一种文件系统加锁方式示意图四;

图7为本申请实施例提供的文件系统加锁方法流程图四;

图8为本申请实施例提供的一种文件系统加锁方式示意图五;

图9为本申请实施例提供的文件系统加锁装置的结构示意图一;

图10为本申请实施例提供的文件系统加锁装置的硬件示意图。

通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

分布式文件系统可以向用户提供并发访问功能,通过多线程的方式来处理用户的请求,并且内部通过全局锁的方式来控制多线程访问,进而允许用户像操作本地文件系统一样使用分布式文件系统。通过全局锁来控制多线程访问虽然保证了数据的一致性,但是也由于全局锁的存在导致单个线程持有锁的时间较长,进而导致多线程的并发处理能力不能充分得到利用,尤其是在多用户大压力访问的情况下,分布式文件系统不能充分并发处理请求。

为了有效提升文件系统的并发处理能力,本发明设计了一种文件系统加锁方法,文件系统客户端根据客户端机器发送的多线程访问请求,将访问同一目标文件的多个目标线程同时处理。通过将目标线程分为请求阶段和数据访问阶段,使得在文件系统客户端针对同一目标文件的多个目标线程时,能够同时并发处理多个目标线程的请求阶段,再根据不同目标线程各自的访问类型,在不同的时间段对目标文件进行加锁,使得不同目标线程的数据访问阶段互斥进行。

本申请提供的文件系统加锁的方法,旨在解决现有技术的如上技术问题。

图1为本申请实施例的系统架构图,结合图1对本申请的系统架构进行介绍。如图1所示,本申请的系统包括客户端机器101以及文件系统客户端102。客户端机器101能够运行相应进程,进而使得文件系统客户端102为该进程提供对文件系统的访问。文件系统客户端102能够为Ceph-fuse客户端。在本申请的系统中,客户端机器101上面的用户程序能够访问挂载点,进而使得挂载点上的请求能够通过系统调用进入内核态的fuse模块。fuse模块通过字符设备将请求发送到用户态的libfuse模块。libfuse模块通过多线程来处理请求,并将请求发送到文件系统客户端102。在挂载过程中,文件系统客户端102能够与元数据服务器(MetaData Server,MDS)建立通信,并获取根目录的元数据信息。挂载完成后,文件系统客户端102能够为客户端机器101提供标准文件系统接口,如读、写、创建、删除文件等。在文件系统客户端102中的线程在处理请求时,能够通过锁模块对请求的目标文件进行上锁,然后进行元数据或者数据的处理,直到需要通过消息模块发送请求到MDS或者Rados(Reliable,Autonomic Distributed Object Store)时才释放锁。在请求对应的数据操作完成后,文件系统客户端102能够将操作结果返回给客户端机器101。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本申请的实施例进行描述。

图2为本申请实施例提供的文件系统加锁方法流程图一。如图2所示,本实施例的执行主体可以为上述图1实施例中的文件系统客户端102,该方法包括:

S201、获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识。

具体地,客户端发送的访问请求能够用于操作文件系统客户端中的文件和文件对应的目录,以及访问元数据信息。例如,访问请求可以是getattr请求、写请求等。getattr请求能够用于获取文件或者目录的属性信息。写请求能够用于向文件中写入数据。

可选地,待访问文件的标识可以是目标文件的请求路径,文件系统客户端根据每个访问请求携带的请求路径使客户端访问指定的目标文件或目录。

在具体实现过程中,文件系统客户端获取客户端发送的多线程的访问请求,并且每个访问请求中携带待访问文件的标识。

S202、根据待访问文件的标识,获取访问同一目标文件的至少两个目标线程。

具体地,文件系统客户端能够根据客户端发送的至少两个访问请求中的标识确定客户端需要访问的目标文件,从线程池中选择至少两个目标线程,并将上述至少两个目标线程作为处理上述至少两个访问请求的目标线程。

S203、根据至少两个目标线程各自的访问类型,在不同的时间对目标文件进行加锁,以使得至少两个目标线程的请求阶段并发执行,数据访问阶段针对目标文件的同一数据域读写互斥。

具体地,目标线程可以分为请求阶段和数据访问阶段。请求阶段可以包括客户端身份验证和权限验证。例如,身份验证可以通过客户端提供的用户名和密码或者令牌等实现。进一步地,身份验证阶段不需要对访问的资源进行锁定。由于上述身份验证阶段不需要访问或者修改文件系统客户端中的共享资源,因此,身份验证阶段不需要获取锁。又例如,权限验证可以检查客户端对请求的目标文件或者目录的访问权限,进而确保客户端有权执行上述请求操作。数据访问阶段能够为根据目标线程各自的访问类型执行相应的读写操作。

在具体实现过程中,文件系统客户端能够同时处理至少两个目标线程的请求阶段,以使得至少两个目标线程的请求阶段能够并发执行,并根据不同目标线程各自的访问类型,在不同时间对目标文件进行加锁,使得目标文件的同一数据域读写互斥。

本实施例提供的文件系统加锁方法,通过将访问同一目标文件的多个目标线程分为请求阶段和数据访问阶段,使得在文件系统客户端针对同一目标文件的多个目标线程时,能够同时并发处理多个目标线程的请求阶段,再根据不同目标线程各自的访问类型,在不同的时间段对目标文件进行加锁,使得不同目标线程的数据访问阶段互斥进行。

图3为本申请实施例提供的文件系统加锁方法流程图二。本实施例在上述图2实施例的基础上,在目标线程的访问类型包括写请求类型和getattr访问类型的情况下,对写请求类型和getattr访问类型对其目标文件进行加锁的过程进行详细说明。如图3所示,该方法包括:

S301、获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识。

S302、根据待访问文件的标识,获取访问同一目标文件的至少两个目标线程。

步骤S301-S302与图2实施例中的步骤S201-S202类似,本实施例在此不做赘述。

S303、若至少两个目标线程的访问类型包括写请求类型和getattr访问类型,则在写请求类型对应的第一目标线程对目标文件进行请求处理时对目标文件加全局锁。

在一种可能的设计中,如果至少两个目标线程的访问类型包括写请求类型和getattr访问类型,则优先处理写请求类型。并且,在写请求类型对应的第一目标线程向目标文件写入数据时,文件系统客户端能够为上述第一目标线程获取全局锁。全局锁能够在任意时刻只允许一个线程获得该锁,并阻塞其他线程的访问。全局锁能够避免多个线程同时访问临界区,避免多个线程同时操作发生冲突。临界区能够避免并发访问引起的竞态条件和数据不一致性问题。例如,临界区可以是多线程环境中的共享变量或者共享资源。

在一种可能的设计中,写请求类型的访问请求为创建目录mkdir的请求。

在一种可能的设计中,在至少两个目标线程的访问类型包括写请求类型和getattr访问类型时,至少两个目标线程的至少两个请求阶段能够并发处理,在至少两个目标线程的至少两个请求阶段并发处理完后,为至少两个目标线程中的任一目标线程的数据访问阶段配置写锁,并且不同目标线程的数据访问阶段互斥进行。

S304、在写请求类型对应的第一目标线程对目标文件进行请求处理时,对getattr访问类型对应的第二目标线程进行身份验证,以执行请求阶段,其中,第二目标线程的请求阶段与请求处理并行执行。

具体地,第一目标线程对目标文件进行请求处理包括第一目标线程的请求阶段和第一目标线程的数据访问阶段。第二目标线程的请求阶段与第一目标线程的请求处理并行执行。并且,第二目标线程的请求阶段能够与第一目标线程请求处理中的任一阶段并行执行。例如,第二目标线程的请求阶段能够与第一目标线程请求处理中的请求阶段并行执行,第二目标线程的请求阶段还能够与第一目标线程请求处理中的数据访问阶段并行执行。

具体地,结合图4A-图4B对图3实施例进行进一步说明。图4A为目标线程的访问类型包括写请求类型和getattr访问类型的情况下,本申请实施例提供的一种文件系统加锁方式示意图一。图4B为目标线程的访问类型包括写请求类型和getattr访问类型的情况下,本申请实施例提供的一种文件系统加锁方式示意图二。

图4A能够表示现有文件系统加锁方式。如图4A所示,若至少两个目标线程的访问类型包括写请求类型和getattr访问类型时,传统的文件系统加锁方式为:文件系统客户端为线程一的写请求配置全局锁,在上述线程一完成请求阶段的身份验证和权限验证后,客户端向目标文件中写入数据或者修改数据,在对目标文件进行修改后,文件系统客户端释放全局锁。在文件系统客户端释放全局锁后,为getattr访问请求配置全局锁。上述写请求的请求阶段和数据访问阶段与getattr访问请求的请求阶段和数据访问阶段互斥进行。

图4B能够表示本申请实施例的文件系统加锁方式。如图4B所示,若至少两个目标线程的访问类型包括写请求类型和getattr访问类型时,本申请实施例的文件系统加锁方式为:文件系统客户端为线程一的写请求配置全局锁,在线程一对目标文件进行请求处理的同时,对线程三中的getattr访问请求进行身份验证。在文件系统客户端为线程一的写请求释放锁后,在线程三中的getattr访问请求身份验证通过后,为线程三中的getattr访问请求的数据访问阶段配置锁。这样,通过本申请在为线程一的写请求配置全局锁,并对线程一的目标文件进行处理的同时,并发执行线程三中的getattr访问的请求阶段,能够提高文件系统的并发处理能力。

S305、在身份验证通过后,在目标文件解锁后,对缓存的元数据加读锁,获取对元数据进行缓存的历史时间戳以及当前时间戳。

具体地,元数据对应的元数据信息缓存在文件系统客户端的内存中。例如,元数据信息数据的存储位置信息、历史数据信息、资源查找信息、文件记录信息等。将元数据信息缓存在文件系统客户端的内存中,能够提高文件系统客户端的性能并且能够较少客户端对文件系统客户端的频繁访问。历史时间戳可以是文件系统客户端上一次对元数据信息进行缓存的时间。当前时间戳可以是文件系统客户端对缓存的元数据加读锁的时间。

在一种可能的设计中,文件系统客户端能够利用其缓存的元数据信息满足客户端对文件的访问需求,无需每次都与文件系统客户端中的MDS进行通信,在缓存的元数据信息未过期的请求下,文件系统客户端能够直接向客户端返回缓存的元数据信息。

S306、根据当前时间戳与历史时间戳获取元数据的生命时长。

具体地,元数据的生命时长为当前时间戳与历史时间戳之间的差值。生命时长的预设范围能够根据目标文件的修改频率和重要性适应性调整。例如,生命时长的预设范围能够为5s或者5min。

S307、判断生命时长是否超过预设范围,若是,则执行S308;若否,则执行S309。

S308、确定元数据未过期,从元数据中读取访问请求对应的目标数据并返回。

具体地,目标数据可以为目标文件的内容数据。例如,文本文件、图像文件、视频文件等。

在具体实现过程中,文件系统客户端在确定其缓存的元数据未过期时,能够从缓存的元数据中读取第二目标线程中getattr访问类型对应的目标文件的元数据中的目标数据,并将目标数据返回至客户端。

S309、确定元数据已过期,向MDS元数据服务器发送请求,并对元数据加写锁,通过写锁将请求得到的元数据更新至缓存中。

在具体实现过程中,文件系统客户端向MDS元数据服务器发送请求,获取最新的元数据。对文件系统客户端中缓存的元数据加写锁,确保在更新期间,其他线程不能读取或者修改缓存的元数据。通过获取的写锁将最新的元数据更新到缓存中,并向客户端返回更新后的元数据。

本实施例提供的文件系统加锁方法,在至少两个目标线程的访问类型包括写请求类型和getattr访问类型时,能够将getattr访问类型对应的第二目标线程的请求阶段与写请求类型对应的请求处理并行执行,并且在第二目标线程身份验证通过后,在第一目标线程对应的目标文件解锁后,能够为第二目标线程的数据访问阶段加读锁,进而提高文件系统的并发处理能力。

图5为本申请实施例提供的文件系统加锁方法流程图三。本实施例在上述图2实施例的基础上,在目标线程的访问类型均为写请求类型的情况下,对写请求类型为其目标文件进行加锁的过程进行详细说明。如图5所示,该方法包括:

S501、获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识。

S502、根据待访问文件的标识,获取访问同一目标文件的至少两个目标线程。

步骤S501-S502与图2实施例中的步骤S201-S202类似,本实施例在此不做赘述。

S503、若至少两个目标线程的访问类型均为写请求类型,则至少两个目标线程的请求阶段并发执行。

S504、根据至少两个目标线程各自对应的写请求的目标文件的数据域,在同一时间段,对至少两个目标线程的不同数据域分别并发加作用域锁以进行写操作,在不同数据域写操作完毕后,对各数据域进行解锁。

具体地,目标文件的数据域为目标文件中的不同数据部分,能够通过功能进行划分。例如,配额quota数据域,内联信息数据域,cap权限数据域等。

在一种可能的设计中,目标线程能够划分为多个作用域,在对至少两个目标线程进行写操作时,文件系统客户端能够在同一时间段对不同目标线程中的不同数据域并发进行写操作。

具体地,结合图6A-图6B对图5实施例进行进一步说明。图6A为本申请实施例提供的一种文件系统加锁方式示意图三。图6B为本申请实施例提供的一种文件系统加锁方式示意图四。图6A能够表示目标线程的访问类型均为写请求类型的情况下,现有文件系统的加锁方式,图6B能够表示目标线程的访问类型均为写请求类型的情况下,本申请实施例的文件系统加锁方式。

如图6A所示,在至少两个目标线程的访问类型均为写请求类型的情况下,传统的文件系统加锁方式为:文件系统客户端为线程一的写请求配置全局锁,在上述线程一完成请求阶段的身份验证和权限验证后,客户端向目标文件中写入数据或者修改数据,在对目标文件进行修改后,文件系统客户端释放全局锁。在文件系统客户端释放全局锁后,为线程三的写请求配置全局锁。上述线程一的写请求的请求阶段和数据访问阶段与线程三的写请求的请求阶段和数据访问阶段互斥进行。

如图6B所示,在至少两个目标线程的访问类型均为写请求类型的情况下,本申请实施例的文件系统加锁方式为:文件系统客户端将线程一和线程三的写请求划分为请求阶段和数据访问阶段。请求开始为请求阶段,用于验证身份和权限信息。数据访问阶段根据功能划分为作用域1、作用域2。文件系统客户端对线程一和线程三的请求阶段并发处理,在对线程一和线程三的请求阶段并发处理后,为线程一的作用域1和线程三的作用域2上锁,对线程一的作用域1和线程三的作用域2并发执行写操作。在对线程一的作用域1和线程三的作用域2并发执行写操作后,释放锁。并且为线程一的作用域2和线程三的作用域1上锁,进而对线程一的作用域2和线程三的作用域1并发执行写操作。这样,通过本申请实施例将至少两个目标线程的访问类型均为写请求类型的目标线程按照功能进行划分,将请求的粒度进行细化,使得文件系统客户端在处理不同目标线程的不同数据域时,能够将二者并发执行,减少了数据域上锁的等待时间,提高了文件系统的并发处理能力。

S505、在下一时间段,对至少两个目标线程的其它不同数据域分别并发加作用锁以进行写操作,在其它不同数据域写操作完毕后,对各数据域进行解锁,重复执行上述加锁和解锁操作,直至每个目标线程完成写操作。

在一种可能的设计中,若至少两个目标线程的数据域数量不同,则存在部分目标线程先完成请求处理,部分目标线程后完成请求处理的情况。文件系统客户端中先完成请求处理的目标线程能够等待后完成请求处理的目标线程,直至最后一个目标线程完成请求处理。

本实施例提供的文件系统加锁方法,在至少两个目标线程的访问类型均为写请求类型时,通过将目标线程按照功能进行划分,将写请求的粒度进行细化,使得文件系统客户端在处理不同目标线程的不同数据域时,能够将二者并发执行,减少了数据域上锁的等待时间,提高了文件系统的并发处理能力。

图7为本申请实施例提供的文件系统加锁方法流程图四。本实施例在上述图2实施例的基础上,在目标线程的访问类型均为getattr访问类型的情况下,对getattr访问类型为其目标文件进行加锁的过程进行详细说明。如图7所示,该方法包括:

S701、获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识。

S702、根据待访问文件的标识,获取访问同一目标文件的至少两个目标线程。

步骤S701-S702与图2实施例中的步骤S201-S202类似,本实施例在此不做赘述。

S703、若至少两个目标线程的访问类型均为getattr访问类型,则至少两个目标线程对应的请求阶段并发执行。

在一种可能的设计中,在至少两个目标线程的访问类型均为getattr访问类型并且在至少两个目标线程对应的请求阶段并发执行后,还包括:

判断至少两个目标线程缓存的元数据是否过期。若至少两个目标线程缓存的元数据均为过期,则文件系统客户端向客户端返回其缓存的元数据。

S704、在至少两个目标线程缓存的元数据均已过期时,并发对元数据加读锁,向MDS元数据服务器发送请求,并对元数据加写锁,通过写锁将请求得到的元数据更新至缓存中,至少两个目标线程的写锁互斥。

具体地,结合图8对图7实施例进行进一步说明。图8为本申请实施例提供的一种文件系统加锁方式示意图五。如图8所示,若至少两个目标线程的访问类型均为getattr访问类型时,本申请实施例的文件系统加锁方式为:文件系统客户端并发处理线程一和线程三的请求阶段。在线程一和线程三的getattr访问请求身份验证通过后,为线程一和线程三对应的目标文件在文件系统客户端中缓存的元数据配置读锁,进而判断缓存的元数据是否过期。若线程一和线程三对应的目标文件的缓存元数据均已过期,则在线程一和线程三释放读锁后,分别为线程一和线程三对应的缓存元数据配置写锁。并且,线程一和线程三的写请求互斥执行。

本实施例提供的文件系统加锁方法,在至少两个目标线程的访问类型均为getattr请求类型时,通过将至少两个目标线程的请求阶段和数据请求阶段中的配置读锁阶段并行处理,能够提高文件系统的并发处理能力。避免多个目标线程对同一目标文件进行getattr请求时,为每个请求配置全局锁,导致不同目标线程的不同getattr请求的请求阶段和数据请求阶段中的获取读锁阶段不能并行处理,降低文件系统的并发处理能力。

图9为本申请实施例提供的文件系统加锁装置的结构示意图一。如图9所示,该文件系统加锁装置90包括:接收模块901、获取模块902、锁模块903。

接收模块901,用于获取客户端发送的多线程的访问请求,每个访问请求中携带待访问文件的标识。

获取模块902,用于根据待访问文件的标识,获取访问同一目标文件的至少两个目标线程。

锁模块903,用于根据至少两个目标线程各自的访问类型,在不同的时间对目标文件进行加锁,以使得至少两个目标线程的请求阶段并发执行,数据访问阶段针对目标文件的同一数据域读写互斥。

在一种可能的设计中,锁模块903还用于:

若至少两个目标线程的访问类型包括写请求类型和getattr访问类型,则在写请求类型对应的第一目标线程对目标文件进行请求处理时对目标文件加全局锁,并控制getattr访问类型对应的第二目标线程执行请求阶段,其中,第二目标线程的请求阶段与请求处理并行执行,请求处理包括请求阶段和数据访问阶段。

在一种可能的设计中,锁模块903还用于:

对客户端进行身份验证,以执行请求阶段;

控制getattr访问类型对应的第二目标线程执行请求阶段之后,方法还包括:

在身份验证通过后,在目标文件解锁后,对缓存的元数据加读锁,获取对元数据进行缓存的历史时间戳以及当前时间戳;

根据当前时间戳与历史时间戳获取元数据的生命时长;

若根据生命时长确定元数据未过期,则从元数据中读取访问请求对应的目标数据并返回;

若根据生命时长确定元数据已过期,则向MDS元数据服务器发送请求,并对元数据加写锁,通过写锁将请求得到的元数据更新至缓存中。

在一种可能的设计中,锁模块903还用于:

若至少两个目标线程的访问类型均为写请求类型,则至少两个目标线程的请求阶段并发执行;

根据至少两个目标线程各自对应的写请求的目标文件的数据域,对至少两个目标线程写请求的数据域加作用域锁以进行写操作,以使得不同目标线程对同一数据域的写请求互斥。

在一种可能的设计中,锁模块903还用于:

根据至少两个目标线程各自对应的写请求的目标文件的数据域,在同一时间段,对至少两个目标线程的不同数据域分别并发加作用域锁以进行写操作,在不同数据域写操作完毕后,对各数据域进行解锁;

在下一时间段,对至少两个目标线程的其它不同数据域分别并发加作用锁以进行写操作,并在其它不同数据域写操作完毕后,对各数据域进行解锁,重复执行上述加锁和解锁操作,直至每个目标线程完成写操作。

在一种可能的设计中,锁模块903还用于:

若至少两个目标线程的访问类型均为getattr访问类型,则至少两个目标线程对应的请求阶段并发执行;

在至少两个目标线程缓存的元数据均已过期时,并发对元数据加读锁,向MDS元数据服务器发送请求,并对元数据加写锁,通过写锁将请求得到的元数据更新至缓存中,至少两个目标线程的写锁互斥。

图10为本申请实施例提供的文件系统加锁装置的硬件示意图。如图10所示,本实施例提供的文件系统加锁装置100包括:至少一个处理器1001和存储器1002。该设备100还包括通信部件1003。其中,处理器1001、存储器1002以及通信部件1003通过总线1004连接。

在具体实现过程中,至少一个处理器1001执行存储器1002存储的计算机执行指令,使得至少一个处理器1001执行如上文件系统加锁方法。

处理器1001的具体实现过程可参见上述方法实施例,其实现原理和技术效果类似,本实施例此处不再赘述。

本申请还提供一种电子设备,包括:处理器,以及与处理器通信连接的存储器,存储器存储计算机执行指令,处理器执行存储器存储的计算机执行指令,以实现上述文件系统加锁方法。

本申请还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,当处理器执行计算机执行指令时,实现上述视文件系统加锁方法。

上述的计算机可读存储介质,上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于可选实施例,所涉及的动作和模块并不一定是本申请所必须的。

进一步需要说明的是,虽然流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解,上述的装置实施例仅是示意性的,本申请的装置还可通过其它的方式实现。例如,上述实施例中单元/模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。例如,多个单元、模块或组件可以结合,或者可以集成到另一个系统,或一些特征可以忽略或不执行。

另外,若无特别说明,在本申请各个实施例中的各功能单元/模块可以集成在一个单元/模块中,也可以是各个单元/模块单独物理存在,也可以两个或两个以上单元/模块集成在一起。上述集成的单元/模块既可以采用硬件的形式实现,也可以采用软件程序模块的形式实现。

集成的单元/模块如果以硬件的形式实现时,该硬件可以是数字电路,模拟电路等等。硬件结构的物理实现包括但不局限于晶体管,忆阻器等等。若无特别说明,处理器可以是任何适当的硬件处理器,比如CPU、GPU、FPGA、DSP和ASIC等等。若无特别说明,存储单元可以是任何适当的磁存储介质或者磁光存储介质,比如,阻变式存储器RRAM(ResistiveRandom Access Memory)、动态随机存取存储器DRAM(Dynamic Random Access Memory)、静态随机存取存储器SRAM(Static Random-Access Memory)、增强动态随机存取存储器EDRAM(Enhanced Dynamic Random Access Memory)、高带宽内存HBM(High-Bandwidth Memory)、混合存储立方HMC(Hybrid Memory Cube)等等。

集成的单元/模块如果以软件程序模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储器中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储器中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储器包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。上述实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

技术分类

06120116581419