一种面向Docker容器的文件系统资源隔离方法与流程

本发明属于虚拟化系统技术领域，尤其涉及一种面向docker容器的文件系统资源隔离方法。

背景技术：

当前，虚拟化是云计算环境中提升设备利用率的一种关键技术手段。docker的出现推动了操作系统级虚拟化技术的发展，容器凭借其性能高，启动快，开销小，隔离性等特点，开始取代虚拟机在云计算环境中占据越来越重要的地位。然而，虽然容器在性能上比起虚拟机有一定优势，但是隔离性方面却比虚拟机差。本质原因是容器共享相同的操作系统内核。同时，由于容器比虚拟机更轻，相同配置的服务器上可以部署更多的容器，因此容器间的资源竞争会比虚拟机间的资源竞争更激烈。

容器间性能隔离的手段主要借助于内核cgroups系统。它可以为进程提供cpu，memory和i/o隔离。比如，blkio子系统可以为每个进程指定一个权重，当使用cfq调度器进行i/o调度时，每个进程可以获得相应权重的调度时间片，从而可以实现容器间的i/o隔离。但是这些隔离手段都没有办法解决因为共享内核所引起的竞争。比如，当多个容器同时创建文件时，都需要向主机文件系统申请inode，所有文件的inode组织成一个全局的链表并由锁保护，因此当多个容器同时创建文件时，就会因为竞争这个锁相互影响。同时，由于容器共享主机文件系统的资源，当出现一个恶意容器大量创建文件时，会耗尽主机文件系统中所有的inode，导致其它容器无法创建文件。

为了减轻由于共享内核出现的隔离性问题，主要的技术手段是将主机文件系统资源进行划分，抽象成多个互相独立的实体，然后将多个进程i/o栈的共享部分进行分离，使得每个进程具有独立的i/o栈。但是这种方法需要对主机文件系统进行修改，而docker容器使用存储驱动来管理镜像和容器，不同存储驱动对主机文件系统有不同要求。所以这种方法不适用于docker容器。同时，docker的镜像和容器分层的存储特性使得docker容器具有更深更复杂的i/o栈，会引入新的隔离性问题。例如，公开号为cn106874125a的专利文献公开了一种多容器系统间共享系统资源的方法及装置，该方法包括：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；基于系统资源相匹配的资源锁，确定系统资源的状态信息；根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

由上可以看到，docker容器已有的性能隔离手段是直接和硬件相关的性能隔离，无法解决由于共享内核带来的隔离性问题。而解决共享内核带来的隔离性问题的技术手段并不适用于docker容器。因此，本发明试图探寻一种容器文件系统资源的隔离方法，针对容器共享内核中的锁竞争和文件系统资源的竞争，提供一种技术手段，将文件系统资源分配到每个容器文件系统示例中，避开共享，从而防止竞争带来的性能干扰，提升隔离性。

此外，一方面由于申请人所理解的本领域技术人员与审查部门必然有所差异；另一方面由于发明人做出本发明时研究了大量文献和专利，但篇幅所限并未详细罗列所有的细节与内容，然而这绝非本发明不具备这些现有技术的特征，相反本发明已经具备现有技术的所有特征，而且申请人保留依据审查指南相关规定随时在背景技术中增加相关现有技术之权利。

技术实现要素：

如本文所用的词语“模块”描述任一种硬件、软件或软硬件组合，其能够执行与“模块”相关联的功能。

针对现有技术之不足，本发明提供一种面向docker容器的文件系统资源隔离方法，根据容器的访问请求对主机文件系统资源进行分配并确定与所述访问请求对应的锁资源，所述文件系统资源隔离方法至少包括如下步骤：基于锁资源的粒度将所述锁资源划分为能够细化的第一锁和不能够细化的第二锁，并按照配置第一锁的细化副本以构成单独的锁的方式创建若干个新容器；根据新容器所需的文件资源请求参数对主机文件系统资源进行分配并基于分配结果将所述若干个新容器划分为第一标记容器和第二标记容器；在所述第一标记容器或所述第二标记容器执行文件系统操作时存在锁竞争或需要使用文件系统资源的情况下，根据已分配给所述第一标记容器或所述第二标记容器的文件系统资源用量对所述文件系统操作的执行进行控制。

根据一种优选实施方式，在所述新容器创建时执行主机文件系统资源的分配，并且所述分配结果取决于剩余的主机文件系统资源能否满足所述文件资源请求参数，其中：在主机文件系统资源的剩余量大于等于新容器创建的需求量的情况下，为所述新容器分配所需的主机文件系统资源并将其划分为所述第一标记容器，或者在主机文件系统资源的剩余量小于新容器创建的需求量的情况下，所述新容器共享所有剩余的主机文件系统资源并被划分为所述第二标记容器。

根据一种优选实施方式，对所述文件系统操作的执行进行控制至少包括如下步骤：判断所述文件系统操作是否存在锁竞争，在所述文件系统操作存在锁竞争且竞争的锁是所述第一锁的情况下，所述新容器按照获取所述细化副本的方式避免锁竞争；在所述文件系统操作需要获取主机文件系统资源的情况下，所述第一标记容器配置为：在其文件系统操作所需的主机文件系统资源未超过为其分配的主机文件系统资源的情况下继续执行所述文件系统操作，并且所述第二标记容器配置：在其文件系统操作所需的主机文件系统资源未超过底层文件系统剩余的资源的情况下继续执行所述文件系统操作。

根据一种优选实施方式，所述文件系统资源隔离方法还包括如下步骤：在删除所述第一标记容器的情况下，释放为其分配的文件系统资源并对主机文件系统资源的剩余量进行更新；按照直接删除第二标记容器的方式结束其对应的文件系统操作。

根据一种优选实施方式，所述第一锁的细化副本按照如下方式配置至所述新容器：为所述新容器配置相应的联合挂载文件系统挂载实例，并在容器文件系统源码中添加相应的字段信息以使得新容器在创建时其对应的容器文件系统挂载实例中便包含所述细化副本；为联合挂载文件系统挂载实例配置至少一个新的加锁函数，使得在所述新容器执行文件系统操作时，所述新容器能够根据所述加锁函数获取与其对应的联合挂载文件系统挂载实例中的细化副本。

根据一种优选实施方式，在创建新容器时，至少能够根据新容器所运行的负载的特征提出对所述主机文件系统资源的需求，其中：所述主机文件系统资源至少包括由索引节点和文件描述符组成的文件系统软资源。

本发明还提供一种面向docker容器的文件系统资源隔离系统，至少包括文件操作系统调用模块、系统内核和若干个容器，基于文件操作系统调用模块能够将容器中的应用程序的请求传至所述系统内核以调用相应的内核函数完成所需的处理，所述文件系统资源隔离系统至少包括细化锁资源模块和文件系统资源分配模块，其中：所述细化锁资源模块配置为：基于锁资源的粒度将所述锁资源划分为能够细化的第一锁和不能够细化的第二锁；所述文件系统资源分配模块配置为：按照配置第一锁的细化副本以构成单独的锁的方式创建若干个新容器；根据新容器所需的文件资源请求参数对主机文件系统资源进行分配并基于分配结果将所述若干个新容器划分为第一标记容器和第二标记容器；在所述第一标记容器或所述第二标记容器执行文件系统操作时存在锁竞争或需要使用文件系统资源的情况下，根据已分配给所述第一标记容器或所述第二标记容器的文件系统资源用量对所述文件系统操作的执行进行控制。

根据一种优选实施方式，所述文件系统资源隔离系统还包括文件系统资源统计模块，所述文件系统资源统计模块配置为：在创建新容器时，对所述文件系统软资源的总量和剩余数量进行统计以判定是否能为新容器分配所需的主机文件系统资源。

根据一种优选实施方式，所述系统内核至少包括底层文件系统、容器联合挂载文件系统和虚拟文件系统，其中：所述虚拟文件系统中设置有所述内核函数，所述容器联合挂载文件系统配置为实现容器对所述底层文件系统的访问。

根据一种优选实施方式，容器所对应的文件系统操作能够依次经所述虚拟文件系统和所述容器联合挂载文件系统传输至所述底层文件系统，其中：所述容器联合挂载文件系统配置成为每一个容器配置容器文件系统挂载实例。

本发明的有益技术效果：

(1)增加的隔离性：docker原本的性能隔离依赖于cgroups，可以实现cpu，memory和i/o的隔离，但是无法解决共享内核引起的隔离性问题。本发明在这几种隔离方案的基础上，实现了对共享锁和共享文件系统资源的隔离，进一步提升了容器的隔离性。现有的解决共享内核引起的隔离性问题的技术手段没有考虑到容器联合文件系统引入的新的隔离性问题。

(2)简洁灵活的隔离机制：本发明的重点在于对主机文件系统资源进行划分，分配给每个容器，将资源的管理从主机文件系统转移到容器文件系统。从而为容器的文件系统资源的隔离提供了一种技术手段。本发明采用的隔离方案是按需分配，即只要容器所需的文件系统资源可以满足就提供给容器。如果容器所需的文件系统资源无法满足，也不会造成容器创建失败，此时容器仍可以使用主机文件系统剩余的所有资源。

(3)对内核修改小，易于使用：本发明只修改了容器文件系统，它是一个热插拔的内核模块，因此不要重新编译系统内核。只需要对该内核模块进行重新编译和加载即可。

(4)本发明将文件系统资源的使用与记录转移到容器联合挂载文件系统中，使得容器文件系统与底层主机文件系统解耦合，为当前云计算环境中容器自由竞争底层文件系统的资源提供了一种隔离手段，能够防止任一容器垄断底层文件系统资源，同时提升容器文件系统操作的性能。

附图说明

图1是本发明优选的文件系统资源隔离系统的模块架构示意图；

图2是本发明优选的容器创建的细化流程图；

图3是本发明优选的容器执行文件系统操作的细化流程图；和

图4是本发明优选的容器删除的细化流程图。

附图标记列表

1：容器2：文件操作系统调用模块3：系统内核

4：容器文件系统挂载实例

301：底层文件系统302：容器联合挂载文件系统

303：虚拟文件系统302a：细化锁资源模块

302b：文件系统资源统计模块302c：文件系统资源分配模块

具体实施方式

下面结合附图进行详细说明。

为了便于理解，将本发明的关键技术用语进行如下解释：

容器：一种开源应用引擎，能够将软件打包成标准化单元以用于开发、交付和部署。

锁：可以包括共享锁和专用锁，当事务在对某个数据对象进行操作前，可以向系统发出请求以对该数据对象进行加锁，使得事务能够对该数据对象进行控制，并且在该事务释放锁之前，其他事务不能对加锁的数据对象进行更新操作。

主机文件系统资源：由索引节点、文件描述符等构成的文件系统软资源，其用于支持容器执行文件系统操作。

联合挂载文件系统挂载实例：通过例如是aufs联合文件系统将不同的目录联合在一起后统一挂载至所需的目录下，使得存储设备上的计算机文件和目录可供用户通过文件系统进行访问。

加锁函数：用于实现对数据对象进行加锁的程序算法。

实施例1

本发明针对容器共享内核中的锁竞争和文件系统资源竞争引起的隔离性问题，提出了一种面向docker容器的文件系统资源隔离系统，该系统对文件系统操作中使用到的锁进行分析，找出设定数量的粗粒度锁，并且可以为每个容器分配一个细粒度的锁以作为粗粒度锁的副本，从而能够避开多个容器竞争相同的粗粒度锁的问题。同时通过上述修改并不会带来一致性的问题。将文件系统资源分配到每个容器文件系统实例中，避开共享，从而防止竞争带来的性能干扰，提升隔离性。

具体的，如图1所示，文件系统资源隔离系统至少包括若干个容器1、文件操作系统调用模块2和系统内核3。通过文件操作系统调用模块2能够将容器1中的例如是应用程序的请求传给系统内核以调用相应的内核函数完成所需的处理。系统内核3至少包括底层文件系统301、容器联合挂载文件系统302和虚拟文件系统303。虚拟文件系统303中设置有内核函数，当某个进程发布一个面向文件的系统调用时，系统内核3可以调用虚拟文件系统303中相应的内核函数。通过容器联合挂载文件系统302可以实现容器1对底层文件系统301的访问。

优选的，再次参见图1，容器1中的文件系统操作首先会经过虚拟文件系统303而到达容器联合挂载文件系统302，并经过一系列操作转化后到达底层文件系统301。容器联合挂载文件系统302为每一个容器均配置有相应的容器文件系统挂载实例4。每一个容器1共享底层文件系统301，使得容器1之间会在底层文件系统301需要获取锁或者需要获取文件系统资源时出现竞争。本发明通过将原本位于底层文件系统301中的锁分配和文件系统资源分配转移到容器联合挂载文件系统302中以构建细化锁资源模块302a、文件系统资源统计模块302b和文件系统资源分配模块302c。通过细化锁资源模块302a、文件系统资源统计模块302b和文件系统资源分配302c能够控制容器1的资源使用，由于在容器1创建时便完成了资源分配，因此容器1之间不会出现竞争。

优选的，文件系统资源隔离系统在执行文件系统操作时会通过细化锁资源模块302a对其使用到的锁进行分析归类。容器1共享相同的主机文件系统而导致其彼此之间会对锁资源进行竞争。在容器1的使用环境下，部分锁资源可以作特殊处理，通过为每个容器分配单独的副本可以防止容器1竞争共同的锁。即在创建新容器时，会为新的容器分配可以特殊处理的锁。即细化锁资源模块302a在容器1创建时为每一个容器1分配主机文件系统中能够细化的锁。具体的，通过细化锁资源模块能够将锁资源划分为第一锁和第二锁。能够细化的第一锁是通过对文件系统操作的内核代码和docker的源码进行分析统计完成而并不是在容器创建时动态的进行判断。例如，主机文件系统中执行一个第一重命名操作时，由于重命名需要修改文件的源目录src和目的目录des，为了保证文件系统的一致性，在修改前需要对这两个目录进行加锁。假设加锁顺序是先加锁源目录，后加锁目的目录。若此时同时存在一个从目的目录到源目录的第二重命名操作，则第一重命名操作和第二重命名操作的加锁顺序处于相反的状态，最终导致第一重命名操作和第二重命名操作均只能获得其中的一个锁，而无法获得另外一个锁，最终导致死锁的出现。为了防止上述情况的产生，本发明通过主机文件系统提供一个文件系统级的锁，任何一个重命名操作在加锁目录前均需要先获得该文件系统级的锁，从而可以有效地避免死锁的产生。与此同时，主机文件系统中所有的重命名操作都会竞争同一个文件系统级的锁。docker容器可以对对应的重命名操作进行特殊处理，由于docker容器的存储空间相互隔离，因此第一容器的重命名加锁的源目录与第二容器的重命名加锁的源目录不会出现重叠，并且第一容器的重命名加锁的目的目录与第二容器的重命名加锁的目的目录也不会出现重叠，从而避免了死锁的产生。优选的，docker容器不需要去竞争共享的文件系统级的锁，文件系统级的锁能够作为粗粒度的锁，其能够被进一步的细化，即文件系统级的锁可以被划分为第一锁，目录级的锁能够被划分为第二锁。例如，可以为每一个容器的联合挂载文件系统实例分配一个细粒度的副本，并在容器文件系统中实现一个新的重命名加锁函数。当容器执行重命名操作时，会根据新的重命名加锁函数，去获取各自联合挂载文件系统实例中的细化副本，从而便可以避免对粗粒度的锁的竞争，最终提升隔离性。每个容器具有一个容器联合挂载文件系统实例，细化锁资源是将共享的底层文件系统中的锁细化到每个容器联合挂载文件系统实例中，防止不同容器因为竞争共享的锁资源而导致文件系统操作串行执行的问题。docker是一个开源的应用容器引擎，可以让开发者打包其应用或依赖包至可移植的容器中，随后能够发布到任何流行的linux机器上。

优选的，锁资源的细化和文件系统资源分配模块302c中分配的资源具有差异性。文件系统资源分配模块302c中分配的文件系统资源在主机文件系统中是具有总量的，而锁资源并没有总量的限制，其只是将例如重命名操作中的在docker环境下粒度过粗会引起竞争的锁进行细化。因此由于没有总量的限制，只要创建一个容器，便将可以细化的锁分配一份细化的副本给新创建的容器。文件系统资源分配模块302c被配置为为所述新容器配置相应的联合挂载文件系统挂载实例，在容器文件系统源码中添加相应的字段信息以使得新容器在创建时其对应的容器文件系统挂载实例中便包含细化副本，并且为联合挂载文件系统挂载实例配置至少一个新的加锁函数，使得在新容器执行文件系统操作时，新容器能够根据加锁函数获取与其对应的联合挂载文件系统挂载实例中的细化副本。优选的，细化锁资源模块302a为容器1实现了定制化的文件系统操作，当容器1执行文件系统操作时，可以避开原来竞争共享锁的执行路径，转为每个容器1获取与其对应的锁，从而能够提升容器1之间的锁隔离。例如，重命名操作便是文件系统操作的定制化的一种具体表现形式。为了防止对主机中的重命名产生影响，现有技术往往限制了不能改变主机文件系统中重命名操作原有的加锁逻辑。而本发明通过将初始重命名加锁逻辑中文件系统级的锁细化分配给了每个容器，使得容器不再按照初始的加锁逻辑去竞争初始的粗粒度的锁。因此本发明在容器文件系统中为容器配置至少一个新的重命名加锁函数，重命名加锁函数在加锁重命名的目录时会遵循初始的加锁逻辑，此时加锁重命名不会去竞争初始的粗粒度的锁，而是去获取为每个容器分配的细粒度的锁。通过上述方式，主机文件系统中的重命名不会受到影响，并且容器中的重命名操作也能避开对锁资源的竞争，进而能够提升容器的隔离性。具体的，原本的重命名加锁函数的加锁顺序是：主机文件系统粗粒度的锁、源目录的锁、目的目录的锁。进行锁细化之后，假设容器中执行一个重命名，如果还是按原来的加锁函数去加锁，此时还是会竞争到主机文件系统粗粒度的锁。因此需要实现一个新的重命名加锁函数，该重命名加锁函数将加锁的顺序限定为：容器文件系统实例、源目录的锁、目的目录的锁。此时，容器只要按照新的重命名加锁函数加锁就可以避开竞争。

优选的，在创建新容器时，文件系统资源统计模块302b至少能够新容器所运行的负载的特征提出对主机文件系统资源的需求，主机文件系统资源至少包括由索引节点和文件描述符组成的文件系统软资源，其中：当创建新容器时，需要通过文件系统软资源的总量和剩余数量信息来判定是否能为新容器分配所需的资源。文件系统资源统计模块302b包含有主机文件系统中索引节点、文件描述符等文件系统软资源的总量和剩余数量。

优选的，文件系统资源分配模块302c负责文件系统资源的分配。当创建新容器时，会从文件系统资源统计模块302b获取资源的当前使用信息。然后按照新建容器的请求量分配给容器，并更新剩余的资源数量。当删除容器时，会回收容器创建时分配给容器的资源，更新剩余的资源数量。优选的，文件系统资源分配模块还配置为按照配置第一锁的细化副本以构成单独的锁的方式创建若干个新容器。根据新容器所需的文件资源请求参数对主机文件系统资源进行分配并基于分配结果将若干个新容器划分为第一标记容器和第二标记容器。在第一标记容器或第二标记容器执行文件系统操作时存在锁竞争或需要使用文件系统资源的情况下，根据已分配给第一标记容器或第二标记容器的文件系统资源用量对文件系统操作的执行进行控制。

实施例2

本实施例是对实施例1的进一步改进，重复的内容不再赘述。

本发明还提供一种面向docker容器的文件系统资源隔离方法，至少包括如下步骤：

s1：文件系统资源分配模块302c根据容器1的需求对主机文件系统资源进行分配，并按照将容器进行标记的方式对分配不同主机文件系统资源的容器进行区别。

具体的，在通过例如是docker创建容器时会根据容器所运行的负载的特征提出对文件系统资源的需求。不同的容器对文件系统资源具有不同的需求。例如，当容器中运行例如是数据库或者web服务器i/o的密集型的负载的情况下，容器会进行大量的文件创建操作，从而使得容器需要大量的索引节点资源。当容器中运行的是主要用于进行计算的cpu密集型的负载的情况下，容器不会对文件系统资源有过多需求。因此在容器创建时，用户可以根据容器中实际运行的负载，在容器创建的命令行参数中显式指定需要多个文件系统资源。

优选的，文件系统资源分配模块302c根据容器的需求对文件系统资源进行分配。分配结果取决于剩余的文件系统资源能否满足容器的需求。例如，当文件系统资源分配模块302c接收到容器1对文件系统资源的访问请求时，可以获取主机文件系统资源的配置文件，配置文件可以包括主机文件系统资源在不同的容器系统中的占用优先级信息及其使用状态信息。根据主机文件系统资源的配置文件可以确定该容器提出的访问请求所涉及的文件系统资源的使用状态信息。文件系统资源的使用状态信息可以包括文件系统资源在不同的容器中的占用比例信息。最后可以根据该容器所请求的文件系统资源的占用优先级信息和使用状态信息，基于预定的系统资源分配规则确定能否将所请求的文件系统资源分配至提出请求的容器1。

优选的，文件系统资源分配模块配置为在容器创建时对文件系统资源进行分配，并且在容器执行文件系统操作时仅根据容器创建时分配的资源量确定操作能否执行。例如，当文件系统资源分配模块302c接收到容器1对文件系统资源的访问请求时，其会通过文件系统资源统计模块302b查询剩余资源的数量。文件系统资源统计模块302b在docker引擎启动时会向主机文件系统获取所有的文件系统资源信息，比如主机文件系统中还剩多少inode资源可供分配。所以此时文件系统资源模块302b可用根据容器对文件系统资源的需求，判断剩余资源是否可以提供给新创建的容器。

优选的，在根据容器的需求对文件系统资源进行分配后，将不同的容器进行标记以进行区别，从而能都得到第一标记容器和第二标记容器。例如，可以将满足请求条件而完成文件系统资源的容器标记为“已限制”以获得第一标记容器，将不满足请求条件而未完成文件系统资源的容器标记为“未限制”以获得第二标记容器。容器标记为“已限制”表示容器创建时指定了较为合理的资源量，其文件系统资源可以满足，容器在后续执行文件系统操作时仅使用为其分配的资源。容器标记为“未限制”表示容器在创建时指定了过多的文件系统资源，而剩余的资源无法满足分配。例如，假设主机文件系统中具有3000个索引节点资源可用，当docker引擎启动时，文件系统资源统计模块302b会向主机文件系统获取到索引节点资源的可用数量信息。当一个容器完成1000的索引节点资源的请求后，文件系统资源统计模块302b将索引节点资源的可用数量更新为2000。当另一个新创建的容器请求2500个索引节点资源资源时，剩余的2000个索引节点资源是无法满足其使用需求的。由于根据负载特征在容器创建之初指定的文件系统资源仅仅是一个预估值，其并不一定十分准确。例如容器内运行的是i/o密集型的负载，此时用户可能在创建该容器时设定了较大的索引节点资源所需值，该索引节点资源所需值大于其实际所需的索引节点资源量。故而为了使得创建时无法满足初始资源分配的容器正常启动，本发明将其标记为“未限制”，表示该容器在创建时指定了过多的文件系统资源，而剩余的资源无法满足分配。针对标记为“未限制”的容器，其共享剩余的所有文件系统资源。标记为“已限制”表示容器创建时指定了较为合理的资源量，其所需的文件系统资源能够得到满足，该容器在后续执行文件系统操作时仅使用创建时为其分配的资源。本发明的资源分配方式相比于现有技术中所有容器共享主机文件系统资源的方式，一者，为用户提供了一种限制容器对主机文件系统资源使用的手段，即在容器创建时用户可以根据需要在创建容器的命令中指定所需的文件系统资源数量。二者，本发明的资源分配方式完全实现在容器文件系统中，并不需要修改主机文件系统，也不需要频繁的与主机文件系统交互，只需要在docker引擎启动时，由文件系统资源统计模块302b向主机文件系统资源获取一次即可。具体的，如图2所示，在创建容器时，为容器分配独立的锁，并判断剩余的文件系统资源能够满足容器的需求。当能够满足容器的需求时便为该容器分配所需的文件系统资源并且将该容器标记为“已限制”。当剩余的文件系统资源不能够满足容器的需求时，该容器便按照使用剩余可用的文件系统的方式进行创建，并将该容器标记为“未限制”。即在主机文件系统资源的剩余量大于等于新容器创建的需求量的情况下，为新容器分配所需的主机文件系统资源并将其划分为第一标记容器；在主机文件系统资源的剩余量小于新容器创建的需求量的情况下，新容器共享所有剩余的主机文件系统资源并被划分为第二标记容器；并且第一标记容器在执行文件系统操作时仅使用为其分配的文件系统资源，第二标记容器在执行文件系统操作时共享剩余的所有文件系统资源。

优选的，容器联合挂载文件系统302可以按照如下方式对文件系统资源进行分配：

a1：细化锁资源模块302a配置为针对可以细化处理的锁，为新创建的容器分配一个单独的副本以防止在进行相应文件系统操作时多个容器竞争共享的锁。具体的，可以细化的锁是根据阅读分析源代码总结出来的，并不是在容器创建时动态判断什么锁能细化什么不能细化，因此容器创建时只需简单分配即可。例如，针对可以细化处理的锁，如重命名操作中的文件系统级的锁，细化锁资源模块302a在容器文件系统源码中添加相应的字段信息，使得在容器创建时，容器对应的联合挂载文件系统实例中能够包含有细化副本。即在为每个容器分配联合挂载文件系统实例时，细化的锁便同步分配给相应的容器。具体的，字段信息”即“成员变量”。比如，重命名操作中的粗粒度锁，在主机文件系统的源代码中是一个互斥锁结构的“成员变量”，因为这个粗粒度锁可以被细化，所以只需要在容器文件系统的源代码中添加一个相同的互斥锁结构的“成员变量”。从而每个容器启动时，其文件系统挂载实例中便包含有一个细化的锁。这该过程之所以称之为“细化”，是因为此时每个容器都拥有自己独有的一份，不会引起竞争。而原本主机文件系统中重命名操作中的粗粒度锁，之所以称为“粗”，是因为这个锁只有1个，原本默认的情况下所有容器都会竞争这个锁。所以这个锁对于容器来说太“粗”了。

a2：资源分配模块302c根据新创建容器的文件资源请求参数判断剩余的文件系统资源能否满足容器的需要，若是，跳转到步骤a3，否则转入步骤a4。文件资源请求参数可以包括索引节点的数量等参数，当资源分配模块302c通过容器资源统计模块302b确定剩余可供分配的资源大于等于请求的资源时，资源分配模块便将对应的资源分配新建立的容器。

a3：从主机剩余文件系统资源中将容器所需的资源分配给新创建的容器，并修改剩余资源的数量。接着，转入步骤a5。

a4：当剩余文件系统资源无法满足容器创建时指定的需要时，为了保证容器能正常创建，按照原来的方式创建容器。即不提供初始文件系统资源的分配，容器使用剩余可用的文件系统资源。接着，转入步骤a6。

a5：将容器标记为“已限制”。

a6：将容器标记为“未限制”。

s2：容器1配置为受到控制隔离的方式执行文件系统操作。当容器执行文件系统操作时，如果存在锁竞争或者需要使用文件系统资源，则根据已分配给容器的用量来控制操作的执行。

具体的，如图3所示，文件系统资源分配模块302c配置为按照如下方式对文件系统操作进行控制隔离：

b1：判断文件系统操作是否存在锁竞争，若文件系统操作之间存在锁竞争，则跳转到步骤b2，若文件系统操作之间存在锁竞争，则转入步骤b5。

b2：判断竞争的锁是否是被细化后分配给每个容器的锁，即判断竞争的锁是否是能够被细化的第一锁，若是，则跳转到步骤b3，否则转入步骤b4。

b3：容器获得分配给自己的锁，从而可以避开锁竞争。分配给容器的锁是第一锁的细化副本。

b4：此时，竞争的锁不能被细化，因此无法避免锁竞争。

b5：检测文件系统操作的执行过程中是否需要获得文件系统资源。若需要，则跳转到步骤b6，否则转入步骤b7。

b6：判断文件系统操作所需的文件系统资源是否还有剩余。分为两种情况：如果容器被标记为“已限制”，则判断操作所需的资源是否不超过容器创建时为容器分配的文件系统资源；或者，如果容器被标记为“未限制”，则判断操作所需的资源是否不超过底层文件系统剩余的资源。当文件系统资源有剩余，跳转到步骤b7，当文件系统资源无剩余时转入步骤b8。

b7：继续执行操作。

b8：操作执行失败，返回错误。

优选的，在文件系统操作执行中的某一步(也可以说某一条指令)需要获取一个锁时，便可能存在锁竞争。例如，由于系统中仅存在一个文件系统级的锁，因此当文件系统操作执行需要获取文件系统级的锁时，必然会形成锁竞争。系统中存在大量目录，使得目录级的锁的数量与文件系统中的目录数相关，故而在文件系统操作执行时需要获取目录级的锁的情况下，有可能出现竞争，也有可能不会产生竞争。即若多个文件系统操作同一个目录，则会出现竞争，若操作不同的目录，则不会产生竞争。因此本发明的判断文件系统操作是否存在锁竞争是指：只要文件操作执行中的某一步需要获取一个锁，则统一认为存在竞争。例如，当容器中进行重命名操作时，若按初始的加锁逻辑加锁，首先会获取粗粒度的文件系统级的锁，然后获取重命名源目录和目的目录的锁。因此每获取一个锁之前均将该文件系统操作判定为存在锁竞争以使得该文件系统操作执行步骤b2进行进一步判断。当文件系统操作执行时首先需要获取文件系统级的锁时，由于该文件系统级的锁已经细化分配到了每个容器的联合挂载文件系统实例中，此时会直接跳过步骤b2而执行步骤b3，在步骤b3中只需获取各个容器联合挂载文件系统实例中细化的锁，从而可以避开锁竞争。由于源目录和目的目录的所对应的锁并未进行细化分配，此时判断竞争的锁不能被细化而跳过步骤b2和步骤b3而执行步骤b4。即一个文件系统操作执行流程中每一条指令均会经过步骤b1-b8的判断。优选的，需要获取锁或者文件系统资源的指令在一个操作中只占很少的部分，从而一个文件系统操作中大部分指令都不会获取锁，也不会申请获得文件系统资源，使得大部分指令的流程均直接进入b7。

s3：当删除一个容器时，容器生命周期中所使用的文件系统资源都会被删除，重新变为可分配。为了使剩余资源的信息保持一致性，需要回收最初分配给容器的资源，更新相应信息。

具体的，如图4所示，文件系统资源分配模块302c配置为按照如下方式对文件系统资源进行回收：

c1：判断即将删除的容器在最初创建时是否被标记为“已限制”。若是，跳转到步骤c2，否则转入步骤c3。

c2：释放容器创建时为容器分配的文件系统资源，修改主机文件系统剩余资源的数量。

c3：删除容器。

需要注意的是，上述具体实施例是示例性的，本领域技术人员可以在本发明公开内容的启发下想出各种解决方案，而这些解决方案也都属于本发明的公开范围并落入本发明的保护范围之内。本领域技术人员应该明白，本发明说明书及其附图均为说明性而并非构成对权利要求的限制。本发明的保护范围由权利要求及其等同物限定。