具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一\第二\第三”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本申请所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

为了更好地理解本申请提供的对称式存储集群目录配额管理方法、守护进程装置及系统，首先，对相关技术中的对称式存储集群的目录更新的实现方式及存在的问题进行分析说明。

图2为相关技术中存储桶中目录配额的更新流程示意图，如图2所示，所述存储桶包括：存储桶a和存储桶a^’，在存储桶a和存储桶a^’中都设置有目录层级，在目录A下设有目录B，目录B下设有目录C，各个目录下都可以存放文件，示例性地，目录C下存放有文件D和文件E。当文件D或文件E中的配额更新时，存储桶中的目录根据层级会进行自下而上地配额更新。

在相关技术中，存储桶中的每个文件和目录都有贡献(contri)属性，它表示当前文件或目录向上级目录贡献了多大容量。存储桶中的每个目录还有另外两个关键值：容量(size)属性，它表示当前目录下的所有文件、目录、子目录的总容量；异常(dirty)标志，它用来处理储存桶配额更新过程中的异常情况。需要注意的是，因为根目录没有父目录，所以它没有contri属性。

以下对/A/B/C目录下文件D的大小改变时，配额自下而上的更新过程进行说明，该更新过程可以通过以下步骤实现：

步骤S1，存储桶获取到文件D的大小发生改变。

步骤S2，存储桶设置D的索引节点为inode。

步骤S3，存储桶设置C的索引节点为pinode。

步骤S4，如果pinode为根目录，则跳到S18，如果不是根目录，进入步骤S5。

步骤S5，存储桶获取pinode锁。

步骤S6，存储桶获取inode的最新大小size。

步骤S7，存储桶获取inode的contri属性值。

步骤S8，存储桶计算差值delta＝size–contri。

步骤S9，如果delta为0，则释放步骤S5获得的锁，跳到S18，如果不为0，则执行步骤10。

步骤S10，设置pinode的dirty标志。

步骤S11，给inode的contri属性增加delta。

步骤S12，给pinode的size属性增加delta。

步骤S13，清除pinode的dirty标志。

步骤S14，释放步骤5获得的锁。

步骤S15，设置inode＝pinode。

步骤S16，设置pinode＝parent(inode)。

步骤S17，跳到步骤S4。

步骤S18，结束。

通过以上实现过程可以看出，在相关技术中，在文件大小频繁更新(比如数据追加写)的情况下，单个读取输入/输出(IO，Input/Output)会附带大量自下而上的元数据更新流，并且IO完成时间与目录层级数呈线性关系；其次为目录保证配额的一致性，在同一目录下同时更新多个文件配额时，互斥锁竞争势必会进一步降低IO效率，最终表现为使目录配额更新时延增加，集群吞吐量下降，在部分场景下集群吞吐量降低超过50％。

另外，配额功能与分布式文件存储软件逻辑的实现耦合性太高，配额的一致性、元数据修复、异常情况的处理等各方面均需要慎重设计。实践中往往会出现配额功能的异常，导致整个存储桶不可用的情况，进一步影响整个集群的IO，而且配额功能的逻辑与分布式文件存储软件的逻辑的实现耦合性太高，增加了存储软件设计的难度。

基于相关技术中所存在的问题，本申请实施例提供一种对称式存储集群目录配额管理方法，所述方法应用于守护进程装置，所述守护进程装置用于对称式存储集群目录配额的管理。本实施例提供的方法可以通过计算机程序来实现，该计算机程序在执行的时候，完成本实施例提供的方法中各个步骤。在一些实施例中，该计算机程序可以被守护进程装置中的处理器执行。图3为本申请实施例提供的对称式存储集群目录配额管理装置方法流程示意图，如图3所示，所述方法包括：

步骤S301，当守护进程装置接收到用于设置集群目录的配额阈值的第一操作指令时，确定所述第一操作指令对应的目标目录和所述配额阈值。

本申请实施例中，所述守护进程装置设置在对称式集群系统中，图4为本申请实施例守护进程装置在对称式集群目录配额管理系统的连接示意图，如图4所示，所述守护进程装置410与N个执行装置420连接，每个执行装置420分别与多个存储桶430连接。守护进程装置410用于控制对称式集群中的各个执行设备420，每一执行装置420用于从守护进程装置获取指令，下发给每一执行装置420下的各个存储桶430。

在一些实施例中，如图4所示，所述守护进程装置410与输入装置440连接，守护进程装置410用于从输入装置440接收用于设置集群目录的配额阈值的第一操作指令。本申请实施例中，所述输入装置440可以是和守护进程装置410集成在一起的，也可以是两个独立的设备。示例性地，所述输入装置440与所述守护进程装置410是两个独立的设备，当所述输入装置440接收到第一操作指令时，将所述第一操作指令发送给守护进程装置410，进而守护进程装置410接收到该第一操作指令。本申请实施例中，所述输入装置440包括命令行界面，所述命令行界面通常不支持鼠标，用户通过键盘输入指令，采用命令行界面可以节约输入装置的系统资源。本申请实施例中，输入装置440、守护进程装置410和执行装置420可以是集成在一起的，也可以是相互独立的设备。

本申请实施例中，当守护进程装置410接收到用于设置集群目录的配额阈值的第一操作指令时，守护进程装置410可以对第一操作指令进行解析，以得到第一操作指令携带的目标目录和配额阈值。示例性地，所述第一操作指令为：set(A，limit(A))，此时可以确定目标目录为A目录，配额阈值为limit(A)。

步骤S302，守护进程装置确定集群中所述目标目录的已使用容量。

本申请实施例中，当确定目标目录后，守护进程装置410可以向各个执行装置420发送请求获取各个存储桶430中所述目标目录的已使用容量，当守护进程装置410接收到各个存储桶中所述目标目录的已使用容量时，可以计算出集群中所述目标目录的已使用容量。

示例性的，已使用容量用usage表示，节点用node表示，存储桶用bucket表示，总共有m个存储桶，各个执行装置420下各个存储桶430的已使用容量可以用usage(A，node(bucket(a…m)))表示，各个执行装置420下各个存储桶的目录限制容量可以用limit(A，node(bucket(a…m)))表示，集群目录限制容量可以用limit(A)表示，当获得了各个存储桶430的已使用容量usage(A，node(bucket(a…m)))后，根据卷信息计算出集群目标目录已使用容量usage(A)。

示例性地，usage(A，node(bucket(a)))＝5吉字节(GB，Gibibyte)，usage(A，node(bucket(b)))＝4GB，usage(A，node(bucket(c)))＝5GB，usage(A，node(bucket(m)))＝7GB，那么已使用容量usage(A)＝21GB。

步骤S303，守护进程装置根据所述集群中所述目标目录的已使用容量和所述配额阈值确定每一执行装置下各个存储桶中所述目标目录的目标配额。

本申请实施例中，当守护进程装置410确定集群中所述目标目录的已使用容量和所述配额阈值后，可以判断集群中所述目标目录的已使用容量是否小于配额阈值。如果目标目录的已使用容量小于配额阈值，守护进程装置410可以计算配额阈值与集群中所述目标目录的已使用容量的差值，将差值按预设方法进行分配以得到每一执行装置420下各个存储桶430中所述目标目录的目标配额。所述各个存储桶430中所述目标目录的目标配额都携带有存储桶标识，所述存储桶标识可以是名称、IP地址等。

在一些实施例中，如果目标目录的已使用容量大于配额阈值，则结束流程。

承接上面的示例，通过usage(A)和limit(A)确定各个执行装置420下各个存储桶的目标配额(即新的limit(A，node(bucket(a…m))))。

步骤S304，守护进程装置所述目标配额发送给各个执行装置，以使每一执行装置下的各个存储桶的文件系统根据所述目标配额对所述目标目录的配额进行更新。

本申请实施例中，守护进程装置410将目标配额给各个执行装置420，各个执行装置420将所述目标配额发送给各个存储桶430，当各个存储桶430接收到带有自身标识的目标配额时，根据自身的文件系统根据所述自身标识对应的目标配额进行更新。

本申请实施例提供的对称式存储集群目录配额管理方法，当守护进程装置获取到设置配额阈值指令时，通过该指令确定目标目录和所述配额阈值，并确定集群中该目标目录的已使用容量，根据配额阈值和已使用容量，确定执行装置下各个存储桶中目标目录的目标配额，将所述目标配额发送给各个执行装置，从而使得每个执行装置下的各个存储桶根据目标配额对目标目录进行更新。通过设置守护进程装置来进行目录配额的管理，实现了守护进程装置执行配额管理方法的控制逻辑与对称式存储集群的系统存储软件控制逻辑的解耦，避免了高并发写，目录层级深时目录配额功能对读写流的影响，而且减小了存储软件设计的难度。

在一些实施例中，所述步骤S302“确定集群中所述目标目录的已使用容量”可以通过以下步骤实现：

步骤S3021，守护进程装置发送获取请求给所述各个执行装置，以使所述各个执行装置获取各个存储桶中所述目标目录的已使用容量。

本申请实施例中，所述获取请求用于获取各个存储桶中所述目标目录的已使用容量。示例性地，所述获取请求为：get(A)。当各个执行装置接收到get(A)时，各个执行装置下获取各个存储桶的已使用容量usage(A，node(bucket(a…m)))，在一些实施例中，还包括获取各个存储桶的目录限制容量limit(A，node(bucket(a…m)))及集群目录限制容量limit(A)。本申请实施例中，各个执行装置获取各个存储桶的目标目录的已使用容量，可以通过以下方式实现，各个存储桶采用自身本地文件系统自带的目录配额功能来确定元数据，如果文件个数较少，也可以通过依次获取各个文件的属性进而获取各个存储桶中目标目录的元数据，各个存储桶将所述元数据发送给各个执行装置。本申请实施例中，所述元数据包括：各个执行装置下各个存储桶的已使用容量usage(A，node(bucket(a…m)))，各个执行装置下各个存储桶的目录限制容量limit(A，node(bucket(a…m)))及集群目录限制容量limit(A)。

步骤S3032，守护进程装置从各个执行装置获取各个存储桶中所述目标目录的已使用容量，以使自身确定集群中所述目标目录的已使用容量。

当各个执行装置获取到各个执行装置下各个存储桶的元数据时，各个执行装置将所述元数据发送给守护进程装置，守护进程装置各个存储桶的已使用容量usage(A，node(bucket(a…m)))进行求和得到集群中所述目标目录的已使用容量。

本申请实施例中，守护进程装置通过从执行装置获取各个存储桶中目标目录的元数据，从而根据各个存储桶中目标目录的元数据计算得到集群中目标目录的已使用容量。当守护进程装置确定已使用容量时，可以根据第一操作指令中携带的配额阈值和已使用容量确定各个执行装置下各个存储桶的目标配额。

在一些实施例中，步骤S303“守护进程装置根据所述集群中所述目标目录的已使用容量和所述配额阈值确定每一执行装置下各个存储桶中所述目标目录的目标配额”可以通过以下步骤实现：

步骤S3031，守护进程装置根据集群中目标目录的已使用容量和所述配额阈值确定根据配额阈值设置后集群中目标目录的未使用容量。

本申请实施例中，可以通过配额阈值与所述目标目录的已使用容量的差值确定根据配额阈值设置后集群中目标目录的未使用容量。

步骤S3032，守护进程装置根据未使用容量和每一执行装置下各个存储桶中所述目标目录的已使用容量确定每一执行装置下各个存储桶中所述目标目录的目标配额，其中，当各个存储桶根据所述目标配额更新后，各个存储桶中所述目标目录的未使用容量均衡。

本申请实施例中，可以根据均衡策略来设置各个存储中所述目标目录的目标配额，所述均衡策略为各个存储桶中所述目标目录的未使用容量相差不大。守护进程装置通过原配额阈值和设置的配额阈值的差值确定集群中待分配的配额，然后根据集群中要分配的配额和已使用容量来确定每一执行装置下各个存储桶中所述目标目录的目标配额，当各个存储桶根据所述目标配额更新后，各个存储桶中所述目标目录的未使用容量均衡。示例性地，存储桶A已使用容量为5GB，存储桶B已使用容量为4GB，在设置前的存储桶A和存储桶B的限制容量都为6GB，第一操作指令中的配额阈值为13GB，此时可以计算出待分配的配额为1GB，为了使存储桶A和存储桶B的未使用容量均衡，此时将待分配的配额1GB直接分配给存储桶A，而存储桶B分配的配额阈值为0GB。则存储桶A的目标配额为7GB，而存储桶B的目标配额为6GB。当存储桶A和存储桶B收到目标配额时，存储桶A将自身的配额阈值更新为7GB，而存储桶B不用进行更新。

基于前述的方法，本申请实施例再提供一种对称式存储集群目录配额管理方法，图5为本申请实施例提供的对称式存储集群目录配额管理方法的流程示意图，如图5所示，所述方法包括：

步骤S501，守护进程装置当接收到用于获取集群中目录配额的第二操作指令时，确定所述第二操作指令对应的目标目录。

本申请实施例中，所述第二操作指令输入装置发出的。当守护进程装置接收到第二操作指令时，可以根据第二操作指令确定目标目录。示例性的，守护进程装置接收到get(A)，即确定目标目录为A目录。

步骤S502，守护进程装置发送所述第二操作指令给所述各个执行装置，以使所述各个执行装置获取所述集群中的所述目标目录的配额阈值和各个存储桶中所述目标目录的已使用容量。

承接上面的示例，守护进程装置将get(A)发送给各个执行装置，当各个执行装置接收到get(A)的指令时，各个执行装置获取所述集群中的所述目标目录的配额阈值和各个存储桶中所述目标目录的已使用容量。

步骤S503，守护进程装置根据各个存储桶中所述目标目录的已使用容量确定集群中目标目录的已使用容量。

本申请实施例中，守护进程模块将各个存储桶中所述目标目录的已使用容量进行求和确定出集群中目标目录的已使用容量。

步骤S504，守护进程装置输出所述集群中目标目录的已使用容量和所述配额阈值。

本申请实施例中，守护进程装置向输入装置发送所述集群中目标目录的已使用容量和所述配额阈值，以使得输入装置输出所述集群中目标目录的已使用容量和所述配额阈值。

本申请实施例提供的方法，当从输入装置收到获取配额的指令时，通过守护进程装置获取集群中目标目录的配额阈值和已使用容量，守护进程装置向输入装置输出该集群中目标目录的配额阈值和已使用容量，从而使得用户获得目标目录的配额，方便网管人员对集群目录进行管理。

在一些实施例中，所述方法还包括：

步骤S505，守护进程装置将所述目标目录已使用容量和所述配额阈值发送给标记装置，以使所述标记装置根据所述配额阈值和所述已使用容量提供所述目标目录的配额视图。

本申请实施例中，继续参见图4，守护进程装置410将所述目标目录已使用容量和所述配额阈值发送给标记装置450，标记装置450用于提供查询文件系统(statfs)的接口，当接收到所述目标目录已使用容量和所述配额阈值时，标记装置450根据目标目录已使用容量和所述配额阈值更改tatfs接口的信息，使得与tatfs接口连接的客户端获得容量视图。

在一些实施例中，所述方法还包括：

步骤S507，守护进程装置周期性确定所述目标目录的已使用容量。

步骤S508，守护进程装置将所述已使用容量发送给标记装置，以使标记装置根据所述目标目录的已使用容量和标记装置自身确定的配额阈值提供所述目标目录的配额视图。

本申请实施例中，标记装置获取配额阈值的周期和守护进程装置确定所述目标目录的已使用容量的周期相同。本申请实施例中，标记装置自身确定的配额阈值可以通过以下方式实现：所述标记装置通过直接从存储桶获取存储桶的目录属性，从目录属性中确定集群的配额阈值。

基于前述的实施例，本申请实施例再提供一种对称式存储集群目录配额管理，图6为本申请实施例提供的对称式存储集群目录配额管理方法的流程示意图，如图6所示，所述方法包括：

步骤S601，守护进程装置获取所述目标目录的父目录下所有子目录的已使用容量。

示例性的，A目录为父目录，A目录下的子目录包括：B子目录，C子目录，D子目录。

B子目录、C子目录和D子目录B的配额阈值都是11GB，B子目录已使用容量为10GB，C子目录已使用容量为6GB，D子目录已使用容量为5GB。

步骤S602，当根据所有子目录的已使用容量确定各个子目录的数据不均衡时，守护进程装置获取各个子目录的配额阈值。

承接上面的示例，显然B子目录的数据更多，C和D子目录的数据相对较少，显然数据并不均衡。

步骤S603，守护进程装置根据各个子目录的已使用容量和配额阈值，调整所述目标目录的配额阈值。

由于数据并不均衡，守护进程模块可以调整目录的配额阈值。承接上面的示例，守护进程确定减小C子目录的配额，增大B子目录的配额，此时，守护进程模块根据减小C子目录的配额，增大B子目录的配额，确定各个存储桶C子目录和B子目录的目标配额，将所述各个存储桶C子目录和B子目录的目标配额发送给执行装置，以使所述执行装置将所述各个存储桶C子目录和B子目录的目标配额发送给各个存储桶，从而使得各个存储桶更新自身C子目录和B子目录的配额，从而使得各个子目录的配额阈值均衡。

本申请实施例提供的方法，通过获取父目录下各个子目录的已使用容量，确定各个子目录的数据是否均衡，当不均衡时，对所述各个子目录的配额阈值进行调整，从而使得各个子目录的配额阈值均衡。

基于前述的实施例，本申请实施例提供一种守护进程装置，用于对称式存储集群目录配额管理，该装置包括的各模块、以及各模块包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central Processing Unit)、微处理器(MPU，Microprocessor Unit)、数字信号处理器(DSP，Digital Signal Processing)或现场可编程门阵列(FPGA，FieldProgrammable Gate Array)等。

本申请实施例再提供一种守护进程装置，图7为本申请实施例提供的守护进程装置结构示意图，如图7所示，所述守护进程装置700包括：

第一接收模块701，用于当接收到用于设置集群目录的配额阈值的第一操作指令时，确定所述第一操作指令对应的目标目录和所述配额阈值；

第一确定模块702，用于确定集群中所述目标目录的已使用容量；

第二确定模块703，根据所述集群中所述目标目录的已使用容量和所述配额阈值确定每一执行模块下各个存储桶中所述目标目录的目标配额；

第一发送模块704，用于将所述目标配额发送给各个执行模块，以使每一执行模块下的各个存储桶的文件系统根据所述目标配额对所述目标目录的配额进行更新。

在一些实施例中，第一确定模块702包括：

第一发送单元，用于发送获取请求给所述各个执行装置，以使所述各个执行装置获取各个存储桶中所述目标目录的已使用容量，所述获取请求用于获取各个存储桶中所述目标目录的已使用容量；

第一获取单元，用于从各个执行装置获取各个存储桶中所述目标目录的已使用容量，以使自身确定集群中所述目标目录的已使用容量。

在一些实施例中，第二确定模块703包括：

第一确定单元，用于根据所述集群中所述目标目录的已使用容量和所述配额阈值确定根据配额阈值设置后集群中目标目录的未使用容量；

第二确定单元，用于根据未使用容量和每一执行装置下各个存储桶中所述目标目录的已使用容量确定每一执行装置下各个存储桶中所述目标目录的目标配额，其中，当各个存储桶根据所述目标配额更新后，各个存储桶中所述目标目录的未使用容量均衡。

在一些实施例中，所述守护进程装置700，还包括：

第二接收模块，用于当接收到用于获取集群中目录配额的第二操作指令时，确定所述第二操作指令对应的目标目录；

第二发送模块，用于发送所述第二操作指令给所述各个执行装置，以使所述各个执行装置获取所述集群中的所述目标目录的配额阈值和各个存储桶中所述目标目录的已使用容量；

第三确定模块，用于根据各个存储桶中所述目标目录的已使用容量确定集群中目标目录的已使用容量；

输出模块，用于输出所述集群中目标目录的已使用容量和所述配额阈值。

在一些实施例中，所述守护进程装置700还包括：

第三发送模块，用于将所述目标目录已使用容量和所述配额阈值发送给标记装置，以使所述标记装置根据所述配额阈值和所述已使用容量提供所述目标目录的配额视图；

或，第四确定模块，用于周期性确定所述目标目录的已使用容量；

第四发送模块，用于将所述已使用容量发送给标记装置，以使标记装置根据所述目标目录的已使用容量和标记装置自身确定的配额阈值提供所述目标目录的配额视图。

在一些实施例中，所述守护进程装置700还包括：

第一获取模块，用于获取所述目标目录的父目录下所有子目录的已使用容量；

第二获取模块，用于当根据所有子目录的已使用容量确定各个子目录的数据不均衡时，获取各个子目录的配额阈值；

调整模块，用于根据各个子目录的已使用容量和配额阈值，调整所述目标目录的配额阈值。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例再提供一种对称式存储集群目录配额管理系统，图8为本申请实施例提供的所述对称式存储集群目录配额管理系统的组成结构示意图，如图8所示，所述系统800包括：

守护进程装置810，用于当接收到用于设置集群目录的配额阈值的第一操作指令时，确定所述第一操作指令对应的目标目录和所述配额阈值；确定集群中所述目标目录的已使用容量；根据所述集群中所述目标目录的已使用容量和所述配额阈值确定每一执行装置820下各个存储桶830中所述目标目录的目标配额；将所述目标配额发送给各个执行装置820；

各个执行装置820，用于接收所述目标配额，将所述目标配额发送给各个存储桶830，以使各个存储桶830的文件系统根据所述目标配额对所述目标目录的配额进行更新。

在一些实施例中，所述系统还包括：

输入装置840，用于响应于用户的输入操作，向所述守护进程装置810发送设置集群目录的配额阈值的第一操作指令。

在一些实施例中，所述系统还包括：

标记装置850，用于从守护进程装置810获取集群中所述目标目录的已使用容量和所述配额阈值，以根据所述配额阈值和所述已使用容量提供所述目标目录的配额视图；或，

用于周期性从所述守护进程装置810获取集群中所述目标目录的已使用容量和自身确定的配额阈值提供所述目标目录的配额视图。

在一些实施例中，所述标记装置850还用于当接收改变目标目录中文件大小的读写流时，确定集群中所述目标目录的已使用容量与配额阈值的比值是否满足预设条件，当集群中所述目标目录的已使用容量与配额阈值的比值满足预设条件时，将所述读写流直接写入存储桶。

本申请实施例中，所述集群中所述目标目录的已使用容量与配额阈值的比值当小于一个预设的阈值时，确定满足预设条件，示例性地，当满足预设集群中所述目标目录的已使用容量与配额阈值的比值小于10％时，此时说明集群中目标目录下的空间还较大，此时可以直接将所述读写流写入存储桶830。

在一些实施例中，所述标记装置850还用于当所述确定所述集群的目标目录的已使用容量与配额阈值的比值的不满足预设条件时，判断所述读写流的容量与所述目标目录的可用容量的差值是否小于0；当所述读写流的容量与集群的可用容量小于0时，将所述读写流写入存储桶。

本申请实施例中，如果集群的目标目录的已使用容量与配额阈值的比值大于所述预设的阈值时，此时需要判断集群中目标目录是否能够存储下所述读写流。当所述读写流的容量与所述目标目录的可用容量的差值小于0，直接写入存储桶。

基于前述的各个实施例提供的对称式存储集群目录配额管理系统，本申请实施例再提供一种对称式存储集群目录配额管理系统，所述系统包括：配额命令行界面模块(Quota Cli)(即上文中的输入装置)、配额守护进程模块(Quota Daemon)(即上文中的守护进程装置)、配额执行模块(Quota Enforcer)(即上文中的执行装置)和配额标记模块(Quota Marker)(即上文中的标记装置)。图9为本申请实施例提供的对称式存储集群目录配额管理系统的架构示意图，如图9所示，该系统包括：Quota Cli 901，Quota Daemon 902，Quota Enforcer 903，Quota Marker 904，其中，

Quota Cli 901，用于获取和设置分布式文件存储目录配额信息。以A目录为例，如get(A)为获取目录配额的命令、set(A，limit(A))为设置目录配额的命令。

Quota Daemon 902，用于控制N个节点，Quota Daemon 902可以有多个，但是同时只有一个Quota Daemon 902工作，当一个Quota Daemon 902出现故障时，另外的QuotaDaemon 902接替工作，从而减少停工时间，而保持其服务的高度可用性。

本申请实施例中，Quota Daemon 902具有如下功能：

功能1：接收Quota Cli 901请求，转发信息给Quota Enforcer 903，然后从所有存储桶收集A目录已使用容量usage(A，node(bucket(a…m…m)))，目录限制容量limit(A，node(bucket(a…m)))及集群目录限制容量limit(A)。然后根据卷信息计算出分布式文件存储目录已使用容量usage(A)。如果是获取配额请求则返回usage(A)和limit(A)。如果是设置配额请求，计算新的目录限制容量limit(A，node(bucket(a…m)))，向Quota Enforcer903发送新的limit(A)及新的limit(A，node(bucket(a…m)))；并向Quota Marker 904发送新的usage(A)及limit(A)。

功能2：周期检查集群状态，并修复待修复数据。

功能3：周期性计算usage(A)并发送给Quota Marker 904。

功能4：周期性检查配额目录的数据均衡情况，根据均衡策略决定是否重设目录限制容量limit(A，node(bucket(a…m)))。

Quota Enforcer 903：每个存储节点一个，每个存储节点下有至少一个存储桶，用于维护节点上所有存储桶以下信息：

每个存储桶A目录已使用容量usage(A，node(bucket(a)))，默认采用本地文件系统自带的目录配额功能。如果文件个数较少也可使用遍历累计的方法获取。

A目录限制容量limit(A，node(bucket(a)))。

A目录在集群中的限制容量limit(A)。

Quota Marker 904用于通过usage(A)和limit(A)改造了分布式文件系统的IO服务进程的statfs接口，用来给挂载点提供正确的容量视图；Quota Marker 904还用于周期性从存储桶的目录属性中获得limit(A)。

继续参见图9，其中a、b、c、d、f为各个模块间的交互路径，下面结合对称式存储集群目录配额管理系统对目标目录进行配额管理时，各个模块的交互路径进行说明，下面的各个实施例以目标目录为A目录进行说明。

目录配额获取过程可以通过以下步骤实现：

步骤SA1，Quota Cli 901通过a向Quota Daemon 902发送get(A)。

步骤SA2，Quota Daemon 902接收get(A)后通过b从所有存储桶收集A目录已使用容量usage(A，node(bucket(a…m)))和limit(A)。然后根据卷信息计算出分布式文件存储目录已使用容量usage(A)。

步骤SA3，通过a向Quota Cli 901返回usage(A)及limit(A)。

步骤SA4，完毕。

目录配额设置过程可以通过以下步骤实现：

步骤SB1，Quota Cli 901通过a向Quota Daemon 902发送set(A，limit(A))。

步骤SB2，Quota Daemon 902接收set(A，limit(A))后通过b从所有存储桶收集A目录已使用容量usage(A，node(bucket(a…m)))。然后根据卷信息计算出分布式文件存储目录已使用容量usage(A)。

步骤SB3，Quota Daemon 902计算新的目录限制容量limit(A，node(bucket(a…m)))，通过b向Quota Enforcer 903发送新的limit(A)及新的limit(A，node(bucket(a…m)))。

步骤SB4，步骤3成功后通过d向Quota Marker 904发送新的usage(A)及limit(A)。

步骤SB5，目录配额设置完毕。

目录配额更新过程可以通过以下步骤实现：

步骤SC1，Quota Daemon 903周期检查集群状态，并修复待修复数据，修复完成后进入下一步。

步骤SC2，Quota Daemon 903通过b从所有存储桶收集A目录已使用容量usage(A，node(bucket(a…m)))，目录限制容量limit(A，node(bucket(a…m)))及集群目录限制容量limit(A)。然后根据卷信息计算出分布式文件存储目录已使用容量usage(A)。

步骤SC3，评估目录下数据均衡情况，根据均衡策略决定是否重设目录限制容量limit(A，node(bucket(a…m)))。

步骤SC4，通过d向Quota Marker 904发送新的usage(A)及limit(A)。

步骤SC5，目录配额更新完毕。

容量视图更新过程可以通过以下步骤实现：

步骤SD1，根据从d接收的usage(A)和limit(A)，或Quota Marker 904周期性从存储桶的目录属性中获得的limit(A)和周期性接收usage(A)改造statfs接口，给挂载点提供正确的容量视图。

步骤SD2，结束。

业务IO流程可以通过以下步骤实现：

步骤SE1，改变文件大小的IO通过e发往Quota Marker 904。

步骤SE2，如果usage(A)/limit(A)的比值小于阀值的，直接进入步骤4。

步骤SE3，Quota Marker 904计算delta＝size(IO)-(limit(A)-usage(A))。如果delta<0或者limit(A)-usage(A)<0，则直接返回。

步骤SE4，通过卷信息计算实际IO，并发给存储桶。

步骤SE5，存储桶收到IO后，直接写入本地文件系统。此步也可能会出现存储桶目录配额容量不足的情况，若出现则直接返回。

步骤SE6，完毕。

可以看到整个目录配额更新过程完全依赖存储桶上的本地文件系统的能力，业务IO流程极大缩短。

本申请实施例引入一种对称式分布式文件存储目录配额架构，通过Quota Cli901、Quota Daemon 902、Quota Enforcer 903和Quota Marker 904四大组件提供与分布式文件存储本身高度解耦的目录配额实现方式。集群目录配额的主要实现主要依赖本地文件系统自身的配额功能，高度可定制、实现简单，极大剥离了传统实现方式对分布式文件存储本身的影响。避免了高并发写，目录层级深时目录配额功能对业务IO的影响；通过目录配额更新过程下沉到存储桶上的文件系统的方式，分布式目录配额实际由本地文件系统的配额保证，极大简化了分布式存储软件的设计。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的图像识别方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，ReadOnly Memory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

相应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现上述实施例中提供的对称式存储集群目录配额管理方法中的步骤。

以上存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请图像识别设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台AC执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。