存储虚拟化系统中的多层合并的制作方法

容器是一种类型的虚拟化技术，其允许许多应用在共同主机操作系统下运行，同时保持彼此完全隔离。这种隔离确保容器内部的任何进程都无法看到容器外部的任何进程或者资源。与虚拟机所提供的隔离方法不同，容器不要求使用管理程序，而是使用与操作系统内核相关联的进程隔离和文件系统特征。因此，容器可以提供优于虚拟机的优点，诸如较小的存储要求和缩短的启动时间。容器内的应用和进程可以经由许多文件系统调用与主机文件系统和操作系统交互。

技术实现要素：

所公开的是用于在容器中运行的应用经由普通文件系统调用但以保持与其他容器中的应用和进程隔离的方式访问被存储在磁盘上的文件的技术。在一方面，命名空间虚拟化组件与写入时复制组件耦合。当隔离的应用正访问以只读方式被存储在磁盘上的文件时，命名空间虚拟化组件和写入时复制组件授权对文件的访问。但是，如果该应用请求修改文件，则写入时复制组件拦截i/o并将文件的副本有效地创建在磁盘上的不同存储位置中。然后，命名空间虚拟化组件负责经由命名空间映射隐藏文件的副本的真实位置。因此，对于该应用显得就好像应用正访问并写入其请求的资源一样，但实际上其正对文件的副本进行操作。

提供本发明内容是为了以简化的形式介绍一些概念，其在下面的具体实施方式中被进一步描述。本发明内容既不旨在标识所要求保护的主题的关键特征或者本质特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中提到的任何或者所有缺点的限制。

附图说明

当结合附图阅读时可以更好地理解前述发明内容以及以下的具体实施方式。为了说明本公开，示出了本公开的各个方面。然而，本公开不限于所讨论的具体方面。在附图中：

图1是描绘用于在容器命名空间中创建占位符文件的示例环境的框图。

图2是将对容器的文件访问从容器自己的容器命名空间重新定向到只读命名空间的示例进程的流程图。

图3是处置容器对被存储在容器自己的容器命名空间中的占位符文件的修改(例如写入)的示例进程的流程图。

图4是描绘用于在容器命名空间中创建占位符目录的示例环境的框图。

图5是基于只读命名空间的共享目录来在容器命名空间中创建占位符目录的示例进程的流程图。

图6是处置容器对占位符目录的修改(例如，重命名或者删除)的示例进程的流程图。

图7是描绘针对所加载的文件使用共享存储执行区域的示例环境的框图。

图8a图示根据本文所公开的虚拟化技术的一方面的、通过顶(例如刮)层和单独源层的合并组件的处理的示例。

图8b是进一步图示图8a的合并组件的操作的流程图。

图8c是图示图8a的合并组件的墓碑功能的流程图。

图9a是描绘其中命名空间虚拟化组件使刮层的内容的位置虚拟化的示例环境的框图。

图9b以图形方式图示根据图9a中所图示的示例环境的、虚拟化根、刮层根以及层根之间的关系。

图9c图示将文件打开i/o调用从虚拟化目标重新定向到虚拟化目标根的进程的一个实施例。

图10图示其中可以采用本文所公开的各个方面的示例性计算设备。

具体实施方式

本文所描述的技术和系统使得在容器中运行的应用能够经由普通文件系统调用但以保持与其他容器中的应用和进程隔离的方式访问被存储在磁盘上的文件。在各种示例中，容器包括隔离资源控制机制，一个或多个进程(例如，包括应用的进程)可以通过该隔离资源控制机制在不影响容器外部的其他系统或者主机基础设施的情况下执行。容器可以运行操作系统的一些组件(通常为操作系统组件的子集)，容器可以具有其自己的文件系统命名空间，和/或容器可以通过网络而被访问，就好像其是物理计算机系统(例如，隔离执行的计算机系统)一样。

如上所述，容器依赖于对文件(例如，可执行文件、二进制文件等)的访问来执行容器中所包含的进程。在一些实例中，容器可以与作业相关联。在一个实施例中，容器可以在存储资源(例如，数据中心中的服务器)上具有其自己的容器命名空间(例如，存储容量)。容器命名空间向容器提供文件的视图。

本文所描述的技术和系统通过在容器命名空间中创建占位符文件来减少容器所消耗的存储资源量。占位符文件与对被存储在只读命名空间中的对应共享文件的只读访问相关联。只读命名空间可以被多个不同容器访问。这增加了存储单元的存储密度，因为可以从相同存储单元执行更多容器。本文所描述的技术和系统通过创建占位符目录进一步减少容器所消耗的存储资源量。本文所描述的技术和系统还通过使用共享执行存储区域来减少容器用以执行文件所消耗的存储资源量。

图1是描绘用于在容器命名空间中创建占位符文件的示例环境或者虚拟化系统100的框图。图1图示了多个容器102(1)…102(n)，其中n表示(例如由主机计算设备(诸如图10中所示的主机计算设备)运行的)容器的数目。容器102(1)包括一个或多个进程104，且容器102(n)包括一个或多个进程106。图1还图示了被配置在容器102(1)…102(n)与存储单元110之间的文件系统过滤器108和文件系统109。文件系统过滤器108可以是文件系统109的文件系统堆栈的一部分，并且可以被配置为执行特定输入/输出(i/o)调用的特别处置。例如，应用(例如，进程104)可以通过经由文件系统109的应用编程接口(api)或者计算设备的底层操作系统调用适当的i/o调用来执行文件操作(例如，创建、打开、读取、写入)。这些i/o调用将被传递至文件系统的堆栈，该堆栈可以包括一个或多个文件系统过滤器，诸如文件系统过滤器108。在一种实施方式中，首先，i/o调用将自身传递通过这些过滤器到文件系统109。i/o调用的目标可能具有(例如，以标签和相关数据的形式)与其相关联的、文件系统109可以检测的特别处置指令，该特别处置指令使文件系统将i/o调用向上传递回堆栈以由文件系统过滤器中的一个(诸如文件系统过滤器108)进行特别处置。与i/o调用的目标相关联的标签可以标识适当的文件系统过滤器以提供特别处置。这种特别处置功能的示例是微软(microsoft)的ntfs重新解析点技术。在微软的ntfs重新解析点技术的情况下，如果文件系统对包含(包括用于特别处置的标签和相关数据/指令的)重新解析点数据结构的磁盘上的文件进行访问，则文件系统将i/o请求向上传递回文件系统过滤器堆栈。与重新解析点的标签(即，全局唯一标识符)相对应的文件系统过滤器将i/o识别为与其访问要由该过滤器处置的文件相关。过滤器将处理i/o，并且然后将i/o传递回文件系统以用于在过滤器的帮助下进行适当处置。在本文所描述的占位符文件的情况下，文件系统将i/o请求向上传递回堆栈到文件系统过滤器108，该文件系统过滤器108将根据在下文中描述的方法处置i/o请求。

如上所述，每个容器具有其自己的容器命名空间(例如，容器容量)，并且因此，容器102(1)与容器命名空间112(1)相关联，并且容器102(n)与容器命名空间112(n)相关联。存储单元110的示例包括：机器(例如服务器)、磁盘、磁带、扇区等。在一些实例中，可以将存储单元布置成“排”(例如，行)，并且可以将多个排的存储单元布置成(例如，被配置在数据中心内的)存储单元的“网格”。

如本文中进一步描述的，可以通过覆盖来自只读命名空间114的只读文件来部分地形成容器命名空间。因此，只读命名空间114可以包括文件集合(例如，可执行文件、二进制文件等)，该文件可以单独地跨多个不同容器102(1)…102(n)和/或多个不同容器命名空间112(1)…112(n)而被共享。在各种示例中，只读命名空间114可以包括一个或多个封装层，其中每个封装层可以包含一个或多个文件(例如，可以被扩展到操作系统目录中的文件)。在图1中，例如，第一封装层116可以与主机的基本操作系统(os)层相关联，第二封装层118可以与运行时间层相关联，并且第三封装层120可以与应用层相关联。

为了实现存储单元110的高容器密度(例如，将更多容器命名空间存储在单个服务器上并且减少通常用于存储容器命名空间的存储量)，图1图示了容器命名空间112(1)包括占位符文件122并且容器命名空间112(n)包括占位符文件124。在一个示例中，当容器在其容器命名空间中打开文件时(例如，在容器被启动之后一段时间时)，占位符文件可以(例如，通过文件系统过滤器108)被创建。在另一示例中，可以与所启动的容器相关联地创建占位符文件(例如，针对特定封装层中的预定的文件集合创建占位符文件集合)。占位符文件是表示共享文件的文件。然而，共享文件包含实际文件数据，并且因此，占位符文件的大小与共享文件相比更小，因为占位符文件不包含共享文件中所包含的实际文件数据。相反，占位符文件仅包含共享文件的元数据(例如，文件的安全描述符、文件的属性、文件的扩展属性等)。因此，占位符文件是不具有实际文件数据的实际文件的表示，且占位符文件位于通过容器访问(例如，被使得对于容器可访问)的文件系统(例如，容器命名空间112(1)…112(n)中的一个容器命名空间)中。

因此，占位符文件122和占位符文件124都是单独表示相同共享文件126的文件的实例(例如，每个占位符文件都包含共享文件126的元数据)。文件系统过滤器108使针对容器102(1)…102(n)的占位符文件122、124虚拟化。例如，当容器打开和/或访问文件时，文件系统过滤器108提供对文件数据的访问，该文件数据显得来自占位符文件(例如，文件系统过滤器108向容器102(1)提供其自己的容器命名空间112(1)的视图)，但该文件数据实际上从容器自己的容器命名空间外部的共享位置(例如，只读命名空间114内的位置)而被读取。在各种示例中，由于使用占位符文件，因此容器命名空间能够处置命名空间操作(例如，锁定、独占读取、独占写入等)，而文件系统过滤器108的任务是重新定向输入/输出。

当容器102(1)打开占位符文件122以便请求读取数据时，文件系统过滤器108将请求传递至容器命名空间112(1)(例如，传递至容器命名空间112(1)的输入/输出(i/o)堆栈)。然后，容器命名空间112(1)基于相关联的标签127确定要被打开的文件是占位符文件122。在各种示例中，标签127包括重新解析点。标签127向容器命名空间112(1)指示容器命名空间112(1)外部的另一组件涉及文件的打开，并且容器命名空间112(1)返回标签127(例如，状态重新解析、错误代码等)。最后，标签127被向上传递回文件系统过滤器108，并且由于文件系统过滤器108拥有标签127(例如，文件系统过滤器108是文件的打开中所涉及的其他组件)，所以文件系统过滤器108准备将读取请求从容器102(1)重新定向到只读命名空间114中的共享文件126，共享文件126与占位符文件122相对应。在一个示例中，文件系统过滤器108准备通过打开共享文件126来重新定向读取请求。在占位符文件122和共享文件126都打开的情况下，文件系统过滤器108可以将读取请求从占位符文件122重新定向到共享文件126，使得显得读取被执行于占位符文件122上。换言之，可以从只读命名空间114中的共享文件126为容器102(1)加载文件数据，即使容器102(1)认为文件数据是从其自己的容器命名空间112(1)中的占位符文件122中加载的。

除了重新定向对只读文件的访问之外，文件系统过滤器108还被配置为确保对文件的修改被隔离至与执行该修改的容器相关联的特定容器命名空间。换言之，文件系统过滤器108被配置为提供容器命名空间112(1)…112(n)的写入时复制行为。例如，如果容器102(n)写入占位符文件124(例如，尝试修改被配置为经由占位符文件124访问的文件数据)，则占位符文件124由文件系统过滤器108转换成包含实际文件数据的完全填充文件128。文件系统过滤器108通过用来自共享文件126的实际文件数据填充占位符文件124来执行转换(例如，共享文件126被加载到容器命名空间112(n)中并且写入被执行)。由于不再需要将对容器命名空间112(n)内的该文件的访问重新定向到只读命名空间114中的共享文件126，因此文件系统过滤器108从完全填充文件128移除相关联的标签130(例如，重新解析点)。

因此，文件系统过滤器108能够隔离任何修改，使得这些修改对执行了文件的修改的容器是特定的和/或私有的。这保护了由多个不同容器命名空间112(1)…112(n)使用的共享文件126的完整性。例如，经由容器命名空间112(1)对占位符文件122的访问仍然由文件系统过滤器108重新定向到共享文件126，但是对容器命名空间112(n)内的对应文件的访问由于在容器命名空间112(n)内创建完全填充文件128的修改和写入时复制行为而未由文件系统过滤器108重新定向到共享文件126。

在各种示例中，由容器对文件进行修改的位置(例如，层)可以被称为文件系统的顶层或者刮(scratch)层。文件系统过滤器108在该顶层或者刮层中捕获对容器特定或者私有的任何文件数据，使得修改与和存储单元110和/或主机实体相关联地操作的其他容器和/或容器命名空间隔离。

在各种示例中，如果文件被包含在多于一个的层中(例如多个层重叠)，则最上层(例如，刮层或者应用层120)中的文件取代较下层(例如，基础os层116)中的任何文件。可以通过启动容器，运行所需软件的安装程序并且提交更改来生成新层。然后，可以在容器命名空间、只读命名空间或者主机命名空间(例如，对主机实体可访问的存储容量)上提交或者安装层(例如，作为目录)。

因此，通过利用只读命名空间114中的共享文件，可以实现存储单元110的更高容器存储密度。即，并非多个容器命名空间各自包括相同的完全填充文件，而是多个容器命名空间可以经由其相应的容器命名空间外部的位置(例如，只读命名空间)访问共享文件，只要该共享文件是只被读取(并且不是被写入)即可。

在图1的图示中，将只读命名空间114图示为存储单元110的一部分。在其他实施例中，只读命名空间114可以在远程存储单元，诸如经由网络被耦合至本地计算设备的远程存储单元(未示出)上进行维护。例如，只读命名空间114可以由云存储服务或者提供商维护。

图2、图3、图5以及图6分别图示了用于采用本文所描述的技术的示例进程。示例进程被图示为逻辑流程图，其每个操作表示可以用硬件、软件或其组合实现的操作序列。在软件的上下文中，操作表示被存储在一个或多个计算机可读存储介质上的计算机可执行指令，该计算机可执行指令在由一个或多个处理器执行时将设备或者系统配置为执行所述的操作。通常，计算机可执行指令包括执行特定功能的例程、程序、对象、组件、数据结构等。描述操作的次序不旨在被解释为限制，并且可以以任何次序和/或并行地组合任何数目的所描述的操作以实施进程。此外，可以省略任何单独操作。

图2图示了将对容器的文件访问从容器自己的容器命名空间重新定向到只读命名空间的示例进程200的流程图。示例进程200可以(例如，通过与主机实体相关联地操作的文件系统过滤器108)与图1中所图示的组件相关联地被实施。

在202处，启动容器。在204处，在容器自己的容器命名空间内创建(多个)占位符文件，其中(多个)占位符文件与以只读方式要被访问的共享文件(例如，操作系统的封装层)相关联。在206处，从容器接收访问文件的请求(例如，读取数据的请求)。在208处，将请求传递到容器自己的容器命名空间，并且打开占位符文件。在210处，从容器命名空间中接收标签(例如，错误消息、重新解析状态等)，该标签指示所请求的文件数据不在容器自己的容器命名空间中(例如，不是经由被打开的占位符文件可访问的)。在212处，打开只读命名空间中的对应共享文件，并且将读取请求从容器命名空间重新定向到只读命名空间，共享文件对多个不同容器可访问。在214处，从只读命名空间中的共享文件读取/加载文件数据。

如上所述，可以响应于来自容器的访问其自己的容器命名空间中的文件的请求(例如，在启动容器之后一段时间)而(例如，通过文件系统过滤器108)创建占位符文件。备选地，可以与启动容器相关联地创建占位符文件(例如，在启动特定封装层中的预定的文件集合时自动创建占位符文件集合)。

图3图示了处置容器对被存储在容器自己的容器命名空间中的占位符文件的修改(例如，写入)的示例进程300的流程图。示例进程300可以(例如，通过与主机实体相关联地操作的文件系统过滤器108)与图1中所图示的组件相关联地被实施。而且，在各种示例中，示例进程300可以在图2的示例进程200之后被实施。

在302处，从容器接收修改文件的请求，其中该文件与容器自己的容器命名空间中的占位符文件相对应。在304处，通过将共享文件的文件数据从只读命名空间加载到容器自己的容器命名空间，将与请求相关联的占位符文件转换为完全填充文件，因此可以隔离修改。在306处，实施对完全填充文件的修改(例如，对文件数据执行写入)。为此，随后可以通过容器从容器自己的容器命名空间中的完全填充文件中，而不是从只读命名空间中的由多个容器共享并且包含未经修改的文件数据的共享文件中读取经修改的文件数据。

图4是描绘了用于在容器命名空间中创建占位符目录的示例环境或者虚拟化系统400的框图。图4与图1的相似之处在于：图4图示了多个容器102(1)…102(n)、文件系统过滤器108、相应的容器命名空间112(1)…112(n)以及只读命名空间114。为了节省存储空间，容器命名空间112(1)包括占位符目录402，且容器命名空间112(n)包括占位符目录404。占位符目录表示对应的共享目录406。然而，占位符目录具有将视图限制到目录的内容中的能力，其中内容可以包括文件、亚目录(sub-directories)、子目录(childdirectories)等。例如，当列举占位符目录时，文件系统过滤器108可以合并占位符目录的视图(例如，其可以包含在容器命名空间中已被打开的占位符文件)和对应的共享目录的视图(例如，其可以包含尚未如上文相对于图1描述的容器命名空间中被打开的另一文件)。

例如，容器命名空间112(1)中的占位符目录402可以反映尚未被填充内容(例如，包含文件的子目录或亚目录“d1”和包含文件的子目录或亚目录“d2”)的根目录(例如，“/”目录)408(例如，父节点)。占位符目录402可以仅反映根目录(如参照408)，因为容器102(1)尚未打开“d1”和/或“d2”中所包含的文件，并且因此，尚未打开通过包含“d1”或者“d2”的路径可访问的文件。因此，可能不需要在容器命名空间112(1)中用来自其对应的共享目录406的内容(例如，包括“d1”和/或“d2”及其中所包含的文件的内容)填充占位符根“/”目录。相反，文件系统过滤器108可以基于对应的只读命名空间114的共享目录406(例如，共享根“/”目录)来列举根“/”目录中所包含的内容。

然而，例如，如果容器102(n)访问只读命名空间114中存在于目录“d1”中的文件(例如，封装层中的文件)，则文件系统过滤器108用“d1”的占位符目录410填充容器命名空间112(n)的占位符目录404(例如，根目录“/”)，并且文件系统过滤器108基于该访问在占位符目录“d1”中进一步创建占位符文件。换言之，创建了针对沿访问路径的目录节点的占位符。然而，由于“d2”中所包含的文件没有被容器102(n)访问，因此文件系统过滤器108不在容器命名空间112(n)中针对“d2”创建占位符目录。

因此，为了节省存储空间，文件系统过滤器108被配置为根据需要(例如，在访问和打开文件时)为相应的容器命名空间创建和/或填充占位符目录。

文件系统过滤器108还被配置为确保对占位符目录的修改被隔离至与执行修改的容器相关联的特定容器命名空间。换言之，通过完全填充级别(例如，包含经重命名或者被删除的占位符目录或者占位符文件的直接父目录)来捕获修改，诸如对容器命名空间中的占位符目录或者占位符文件的重命名或者删除。例如，如果共享目录“d1”包含五个文件，并且容器112(n)重命名占位符目录“d1”中的第一占位符文件，则文件系统过滤器108用针对共享目录“d1”中的第二、第三、第四和第五文件的其他占位符文件完全填充或者列举容器命名空间112(n)的占位符目录“d1”410。这将占位符目录“d1”410完全扩展成普通目录(例如，其中占位符文件表示其内容)，并且该扩展使容器命名空间112(n)知道第一占位符文件已经被重命名。占位符文件在容器命名空间的完全扩展目录中的缺失指示文件被删除。

图5图示了基于只读命名空间的共享目录来在容器命名空间中创建占位符目录的示例进程500的流程图。示例进程500可以(例如，通过与主机实体相关联地操作的文件系统过滤器108)与图4中所图示的组件相关联地被实施。

在502处，启动容器。在504处，在容器自己的容器命名空间内创建占位符目录，其中基于只读命名空间中的共享目录来创建占位符目录。在506处，从容器接收访问占位符目录中的文件的请求。在508处，基于该访问来填充占位符目录的内容(例如，在初始占位符目录内填充了占位符子目录或亚目录和/或所访问的文件的占位符文件)。例如，如果容器请求打开根目录下面的目录“d1”中文件“f1”，则文件系统过滤器108用占位符目录“d1”和占位符文件“f1”填充根目录。

图6图示了处置容器对占位符目录的修改(例如，重命名或者删除)的示例进程600的流程图。示例进程600可以(例如，通过与主机实体相关联地操作的文件系统过滤器108)与图4中所图示的组件相关联地被实施。此外，在各种示例中，示例进程600可以在图5的示例进程500之后被实施。

在602处，从容器接收修改占位符目录的请求(例如，重命名或者删除占位符文件或者子占位符目录或亚占位符目录)。在604处，包含要被重命名或者删除的占位符文件或者子占位符目录或亚占位符目录的占位符目录被扩展，并且针对父目录的内容创建占位符(例如，针对除占位符目录中正被重命名或者删除的文件之外的文件创建占位符文件)。在606处，实施对占位符目录的修改(例如，重命名或者删除占位符文件)。

在各种示例中，图5和图6中所描述的示例进程可以与图2和图3中所描述的示例进程相关联地被实施。

图7是描绘了使用针对加载文件的共享存储执行区域的示例环境或者虚拟化系统700的框图。图7与图1和图4的相似之处在于：图7图示了多个容器102(1)…102(n)、文件系统过滤器108、相应的容器命名空间112(1)…112(n)以及只读命名空间114。为了节省存储空间，图7图示了针对(多个)加载文件的共享存储执行区域(例如，经由只读命名空间114访问共享文件126)。

如上所述，图1的示例环境提供(例如，经由通过文件系统过滤器108执行的重新定向)对共享文件的访问。为了执行，共享文件被加载到存储器中并被执行。在各种示例中，存储单元110与主存储器或者永久存储器相关联。然而，执行文件的存储器可以是高速缓存存储器或者运行时间存储器(例如，ram)。因此，图7图示了多个容器102(1)…102(n)可以从相同的共享存储执行区域702而不是其自己的私有存储执行区域执行共享文件。例如，文件系统过滤器108或者存储器管理器可以将共享文件加载到由相应的容器命名空间112(1)…112(n)指向但由只读命名空间114中的共享文件126的相同副本备份的相同的共享存储执行区域702中(如参照704)。然而，如果容器修改要被执行的文件(例如，如上文参照图1和图3描述的)，则将涉及共享存储执行区域702的该进程解耦(例如，停止)，并且对经修改的文件的执行与特定于容器命名空间的私有存储区域相关联。

在各种示例中，共享存储执行区域702的实施可以与图2、图3、图5和图6中所描述的示例进程中的任何一个相关联。

如上文讨论的，上文在图1、图4和图7中所图示和描述的示例虚拟化系统中，文件的状态是通常较小的本地状态(例如，占位符文件)和通常较大的一些外部源状态(诸如由云提供商或者由另一本地文件系统管理的只读命名空间114中维护的外部源状态)的组合。文件系统过滤器驱动器(诸如文件系统过滤器108)负责将部分本地状态和外部源状态覆盖成可以由容器(例如，容器102(1))的应用使用的单个文件系统视图，就好像完整状态存在于本地一样。仅仅为了便于描述而非进行限制，文件系统过滤器的该功能可以被称为“合并组件”。在这种设计中，正在提供实际存储的底层文件系统不知道其正在托管虚拟化的覆盖文件系统。

包括文件系统状态的覆盖可以被称为“层”。通常，顶层是被暴露给应用和用户的本地层。其为本地文件系统的文件系统目录或者完整容量。有时其被称为“刮层”，因为其仅稀疏地被填充有刚好足以捕获应用所进行的修改的状态。然而，当从应用被查看时，该顶层显得具有整个文件系统状态的完整视图，就好像其在本地存在一样。如图8所示，该视图是顶层修改和单独源层的覆盖。在该示例中，存在顶层(即，刮层)802和多个源层0,1,…n。

为了允许经由顶层(刮层)访问任何源层文件，合并组件在文件被打开时填充刮层804中的占位符。在一种实施方式中，占位符是具有重新解析点和重新解析点数据的被填入零的稀疏文件，该重新解析点数据标识备份占位符的完整文件。占位符元数据，诸如安全性描述符、属性和大小从备份文件被复制。在该示例实施方式中，占位符不包含文件数据。占位符由合并组件解释以将应用可见文件与源层中的备份文件链接。在顶层中反映修改，诸如添加新文件、删除文件和重命名文件。这些变化可能需要永久地被存储在顶层中，或者仅暂时性被存储直到它们可以被反映到(多个)源层中为止。在一些场景中，源层可能是不可变的，因此不反映顶层修改。在其他场景中，源层可能是可变的，并且可以预期要将外部变化反映到顶层中。

刮层的该稀疏填充具有对于存储虚拟化实现(例如，云提供商)以及对于容器的优点。在存储虚拟化的情况下，用户可以从云访问巨大的目录树，就好像整个树在刮层中本地存在一样。对于容器，数百个容器可以在一个系统上同时运行。每个容器都可以具有其自己的刮层，但是它们都共享源层。这实现了比可能的每个容器都具有其自己的完整文件集合的情况高得多的存储密度。

图5b是图示根据上面描述且在图8a中图示的合并组件的基础操作的流程图。如图所示，在步骤810中，合并组件(例如，过滤器108)可以将针对文件的占位符作为文件系统的顶层802的一部分存储在本地存储单元110上。如上面提到的，文件将包括被存储在远离本地存储单元110的、文件系统的一个或多个源层(例如，图8a中的源层0、1、...、n)中的数据和状态。占位符将包括文件的至少部分状态。同样如前面提到的，顶层(即，刮层)可以是容器的命名空间的一部分。

如步骤812中所图示的，合并组件有效地向一个或多个应用(例如，图8a中的应用/进程104)暴露文件系统的顶层，使得顶层对于一个或多个应用显得好像该顶层存储文件的整个状态一样。

如步骤814中图示的，合并组件随后可以从应用接收访问已经针对其创建了占位符并且已经将该占位符存储在顶层中的文件的请求。如步骤816中所图示的，合并组件可以响应于访问文件的该应用请求，将文件的被存储在文件系统的顶层中的占位符中的至少部分状态与文件的被远程存储在一个或多个源层中的剩余状态合并，以向请求的应用呈现文件的单个视图。如下面更充分讨论的，在一个实施例中，一个或多个源层中的至少一些源层也可以包含文件的部分状态，并且该合并可以包括：依次地将文件的顶层中的至少部分状态与一个或多个源层中的剩余状态合并，直到得到文件的完整状态。在该实施例中，如果确定一个或多个源层不包含文件的完整状态，则合并组件可以向请求的应用返回错误。

除了上述的各方面之外，还可以提供将删除或者重命名修改记录在顶部文件系统层中的机制。在一个实施例中，可以将正被删除的文件的父目录转换成完整目录。然后，所删除的文件的缺失用作其删除的记录。然而，在该实施例中，一旦将目录转换成完整目录，就掩盖了目录的较低层中的外部变化。在将允许顶层持续反映较低层中的变化同时仍记录删除和重命名修改的另一实施例中，可以采用墓碑(tombstone)机制。

在墓碑机制的一个实施例中，合并组件(例如，文件系统过滤器108)保持跟踪由应用发出的所有删除操作，并且确定是否需要墓碑来记录删除。如果正被删除的文件存在于备份目录中，则可能需要墓碑。如果文件不存在于备份目录中(该文件被新创建在刮层中)，则可能不需要墓碑，因为备份目录中不存在需要被其掩盖的文件。在本实施例中，当文件系统完成删除时，其将该删除通知给合并组件，并且由合并组件在刮层中创建墓碑。由于在根据文件系统删除文件的时间与创建且存储墓碑的时间之间存在窗口，因此合并组件应该防止任何操作在该窗口期间访问刚被删除的层文件。这可以通过将所删除的文件的名称记录在附接到其父目录的表中来完成，并且使对该文件名的操作等待在墓碑的创建之后。

还可以使用墓碑来实现重命名操作。墓碑可以用于标记来自命名空间的源文件的移除。将重命名有效地视作源文件的删除和新文件的创建。注意，如果目标文件名已经存在，则文件系统通常不会允许重命名。如果用户希望将文件重命名为现有墓碑的名称，则文件系统可能会使该操作失败。为了解决该问题，合并组件可以在其允许重命名操作继续进行至文件系统之前删除墓碑。然而，如果重命名操作由于其他原因而失败，则合并组件应该使墓碑复原。

图8c是图示上面讨论的合并组件的基础墓碑功能的流程图。如步骤820所示，合并组件可以从应用(例如，应用/进程104)接收删除或重命名已经针对其创建占位符并且已经将该占位符存储在文件系统的顶层中的文件的请求。作为响应，如步骤822所示，合并组件可以从本地存储单元上的文件系统的顶层删除针对文件的占位符。在步骤824中，合并组件可以防止任何文件系统操作经由顶层访问被请求被删除或重命名的文件，直到已经创建墓碑并且已经将其存储在顶层中为止。如上面描述的，在一个实施例中，这可以通过以下来实现：在文件的删除或重命名之前，将文件的文件名记录在例如本地存储单元上110上的表中，并且然后使对该文件名的任何尝试的文件系统操作等待在墓碑的创建和存储之后。

接下来，在步骤826中，合并组件可以创建墓碑，该墓碑提供对文件的删除或重命名的记录。在步骤828中，合并组件然后可以将墓碑存储在本地存储单元110上的文件系统的顶层中。此时，如步骤830中图示，等待在墓碑创建之后的文件系统操作可以继续进行。

在磁盘上，可以将墓碑实施为具有与其相关联的特别标签的空文件。该标签向文件系统指示：该文件(即，墓碑)是特别的，并且当该文件试图通过应用被打开时，应该由合并组件而不是以正常方式来解释。因此，当应用试图打开被删除的文件时，文件系统将意识到被删除的文件由具有该特别标签(即，墓碑)的文件来表示，并且将让合并组件处置该请求。然后，合并组件能够使该文件对于该应用显得被删除了一样。如果目录被删除并且应用试图打开该目录下的文件，则合并组件可以类似地被通知，并被给予使操作适当地失败(或以其他方式处置操作)的机会，就好像文件被实际删除一样。在大多数情况下，这可能涉及向应用返回指示文件不存在的错误代码，但在某些情况下可能涉及其他操作。

这些情况中的一种情况是在应用试图以特定部署创建文件时，这些部署取决于文件是否存在。例如，如果特定名称存在，则应用可以发出打开特定名称的文件的操作，否则应用应该创建具有该名称的新文件。为了使对于应用显得墓碑与被删除的文件等效，合并组件可以通知文件系统用应用希望创建的文件取代墓碑。这种取代操作将确保没有墓碑和新文件都不存在的窗口。此状况可能导致以下情况：如果存在竞争的创建操作，则可能将层中的被掩盖的文件带回。

然而，注意，创建具有与现有目录墓碑相同名称的目录不能由取代操作处置，因为文件系统通常不会允许这样做。相反，在一个实施例中，合并组件可以删除目录墓碑，将该状态存储在存储器中，并且然后重新发出应用的操作。如果操作失败，则合并文件然后将以与重命名情况类似的方式使墓碑复原。

合并组件可能需要使墓碑显得被删除的另一场景是目录列举。当应用查询目录中的文件列表时，不期望列出被删除的文件。但是因为被删除的文件可以用墓碑表示，因此文件系统可以将这些报告回应用。为了解决这种场景，合并组件可以拦截任何这种查询并从结果集合过滤掉所有墓碑，使得被删除的文件的错觉被保留。这可以通过扫描由文件系统针对上文提到的特别墓碑标签返回的文件并且在将它们返回至应用之前移除这些结果来实现。

如前所述，在上文讨论的实施例中，墓碑可以使删除和重命名操作的前期成本最小化，尤其是在这些操作出现在较大目录中时，因为那些操作涉及从刮层创建针对该目录下的所有文件的占位符，并且然后将目录标记为完整，使得在刮层中不出现对源层目录的修改。因此，墓碑可以允许虚拟化系统与变化层一起工作，并且还可以改善这些常见操作的性能。

至此，描述将重点放在扩展的源层。扩展层仅具有针对下层中所包含的所有文件的完整文件和占位符。这确保每个源层是所有较低层的合并内容的完整表示。在这种情况下，合并组件仅需要合并顶层和第一源层以构建完整视图。这具有简单的益处，但完全扩展的源层具有需要更多存储、创建缓慢的缺点，而且或许更重要的是，它向较低层掩盖了未来的变化。这可能使得难以支持可能需要被应用于较低源层(诸如操作系统基础层)的软件更新。

如结合图8b的描述简要提及的，为了解决此，描述了一种机制，通过该机制，虚拟化系统可以实现被动态合并的稀疏填充的源层。每个稀疏层都可以包含文件系统状态的部分视图。其包含的文件可以取代较低层中的相同文件的版本。稀疏层中的文件可以是完整文件、具有元数据变化的占位符或者墓碑。墓碑指示对文件的删除已经取代了较低层中的文件的存在。稀疏层的目录可以是完全取代较低层中的目录的完整目录、需要与较低层合并的占位符目录、或者取代较低层中的目录的存在的墓碑。

在本文所描述的实施例中，假设合并组件(诸如文件系统过滤器108)将自己合并源层。然而，在其他实施例中，一些源提供商可以执行所有源层的合并，并将单个源层呈现给合并组件，以使其可以与顶层合并。

在本实施例中，将要合并稀疏源层的合并组件配置有稀疏层位置的顺序列表。当通过应用打开尚未在顶层中被填充的文件时，合并组件可以首先尝试在顶层中填充占位符。这需要合并组件在可能需要合并的源层中的一个源层中定位对应文件。如果合并组件在第一源层中找到文件，则合并完成，并且合并组件将在顶层中使用该文件元数据来填充占位符。可以将对该占位符的处置返回至应用，就好像占位符是完整文件一样。在一个实施例中，如果合并组件由于源层中的目录重新解析点(例如，标签)而遭遇重新解析，则其将检查重新解析标识符(id)。如果id指示目录是部分的，则合并组件必须移动到下一层并再次尝试。如果重新解析点指示其为完全填充的目录，则文件不存在，并且合并组件必须将错误返回至应用。如果合并组件定位目录或者文件墓碑，则其类似地完成并且必须将错误返回至应用。

合并稀疏层的另一方面涉及目录列举。目录列举操作涉及较低层的列举结果的合并。列举列表中的每层，除非其中一层指示其被扩展。非稀疏层下面的层可以被省略，因为它们已经被取代。稀疏目录可以通过重新解析信息中的id以与针对文件打开操作所描述的相同方式来标识。

冲突可能在修改稀疏源层时出现。当用来自较低层的未经修改版本的文件的占位符填充刮层时，该占位符仅仅是元数据的高速缓存和源层备份文件的大小。如果备份文件在合并组件离线时(诸如在容器被关闭时)改变，则该“高速缓存”可能变得无效。处置此冲突的一种方式是在层改变时运行工具并且在合并组件恢复在线之前移除这些占位符。如果占位符已由于元数据变化(诸如文件属性或者安全描述符)而被修改，则占位符不再仅是高速缓存，并且该占位符不能被丢弃。在这种情况下，合并组件必须处置占位符的文件大小不再与备份层同步的可能性。优选地，过滤器将确保这些大小保持同步。注意，如果在发生源层修改时合并组件在线，则结果可能是不可预测的。取决于访问经修改的文件的顺序，该变化可能或者可能不被反映在顶层中。

图9a是描绘了文件系统过滤器908用于使虚拟化系统的刮层802的位置虚拟化的示例环境或者虚拟化系统900的框图。仅仅为了便于描述而非进行限制，文件系统过滤器908的该功能可以被称为“命名空间虚拟化组件(nvc)”。下文中描述的是根据其中一个实施例的、命名空间虚拟化组件908的实现的进一步细节。与图1、图4和图7中所描绘的使刮层的内容虚拟化的文件系统过滤器108不同，命名空间虚拟化组件908使该内容的位置虚拟化。

如同图1、图4和图7，图9a图示了多个容器102(1)…102(n)，其中n表示(例如，由主机计算设备(诸如例如图10中所示的主机计算设备)运行的)容器的数目。容器102(1)包括一个或多个进程104，且容器102(n)包括一个或多个进程106。图9a还图示了命名空间虚拟化组件(nvc)，在所图示的实施例中，可以将该命名空间虚拟化组件实施为文件系统过滤器。文件系统过滤器908可以是文件系统109的文件系统堆栈的一部分，并且可以被配置为执行特定输入/输出(i/o)调用的特别处置。例如，应用(例如，进程104)可以通过经由文件系统109的应用编程接口(api)或者计算设备的底层操作系统调用适当的i/o调用来执行文件操作(例如，创建、打开、读取、写入)。这些i/o调用将被传递至文件系统的堆栈，该堆栈可以包括一个或多个文件系统过滤器，诸如文件系统过滤器908。

每个容器都可以具有其自己的容器命名空间，并且因此，容器102(1)可以与容器命名空间112(1)相关联，并且容器102(n)可以与容器命名空间112(n)相关联。这些容器命名空间可以驻留在底层计算设备的存储单元110上。存储单元110的示例包括：机器(例如，服务器)、磁盘、磁带、扇区等。在一些实例中，可以将存储单元布置成“排”(例如，行)，并且可以将多个排的存储单元布置成(例如，被配置在数据中心内)存储单元的“网格”。

如上所述，命名空间虚拟化组件908用于使刮层的位置虚拟化。再次地，为了便于描述而非进行限制，本文将采用以下术语。虚拟化根(vr)是指被投影到容器的命名空间中的文件夹层级的根。刮层根是指容器的刮层的根。层根是指形成正备份刮层的视图的只读部分的有序的层列表。注意，所有这些位置物理地存在于磁盘上。命名空间虚拟化机制不使“根”具体化，“根”不存在于底层存储设备上。图9b以图形方式图示了虚拟化根902、刮层根904以及层根906之间的关系。

如图9b所示，虚拟化根902被投影到容器的命名空间中。命名空间虚拟化组件908将目标为虚拟化根及其在容器的上下文中的后代的i/o调用重新定向到刮层根904。命名空间虚拟化组件908还为刮层根及其后代投影正确名称，使得以上实体将其感知为位于容器的上下文中的虚拟化根中。写入时复制组件也可以是文件系统过滤器908的一部分或者可以是单独的文件系统过滤器或者其他模块的一部分，写入时复制组件负责提供层根906与刮层根904之间的写入时复制行为。

为了执行其命名空间虚拟化功能，命名空间虚拟化组件908可以被配置有一个或多个映射。在一个实施例中，映射由虚拟化根(vr)、虚拟化目标根(vtr)、零个或者多个虚拟化例外根(ver)以及对所需隔离模式的指示组成。在一个实施例中，将映射存储在通过命名空间虚拟化组件908可访问的表中。每当虚拟化系统启动时，可以使该映射表对命名空间虚拟化组件908可访问，或者将该映射表馈送至命名空间虚拟化组件908。在下面的表1中提供了映射的每个字段的进一步细节：

表1.用于映射的数据结构

在本实施例中，支持两种隔离模式，这两种隔离模式分别被称为“软”隔离和“硬”隔离。

在软隔离模式中，命名空间虚拟化组件908使文件打开(即，打开文件的i/o调用)被“重新解析”，即，用新文件路径被重新发出。在这种模式中，后续操作(诸如文件名查询)看到实际被打开的文件(即，它们看到vtr路径而非vr路径)；各种操作未经虚拟化。这种模式也可以被认为是“重新定向模式”。命名空间虚拟化组件908仅重新解析沿vr路径的打开。它并未试图隐藏调用者打开的事物的真实位置。然而，它确实抑制了会向调用者呈现的、调用者无法处理的路径的信息。例如，不论是硬隔离还是软隔离，命名空间虚拟化组件908都可以抑制处于虚拟化根下的硬链路的名称，因为它们对于调用者都是不可访问的。

在硬隔离模式中，命名空间虚拟化组件908重新定向打开，而不是重新解析它们。命名空间虚拟化组件908处置操作(诸如名称查询)，使得调用者仅看到vr路径而非vtr路径，并且某些操作被虚拟化而其他操作被阻止。命名空间虚拟化组件908尝试保持以下错觉：调用者认为其打开的位置是真正被打开的位置。

在硬隔离模式的一个实现中，命名空间虚拟化组件908可以使通常由于难以实施而未被执行的操作失败。命名空间虚拟化组件908可以依赖于遥测技术来了解用户实际上执行的这些操作的常见程度。如果那些操作的使用频率改变，则命名空间虚拟化组件908可以调整其对那些操作的处置。

图9c图示了将文件打开i/o调用从虚拟化目标重新定向到虚拟化目标根的进程的一个实施例。在该实施例中，该进程可以涉及两个阶段：“打开前”阶段和“打开后”阶段。

如图9c所示，在步骤952中，从应用接收文件打开i/o调用。在打开前阶段，如果从应用接收到的文件打开i/o调用不在容器的上下文中，则在步骤956中，命名空间虚拟化组件908将简单地将其传递通过至文件系统以进行处置。

如果文件打开i/o调用在容器的上下文中，则在步骤958中，命名空间虚拟化组件908将在映射表中查找由调用应用提供的文件的目录路径。如果路径不在映射表中，或者如果其映射包含虚拟化例外根，则在步骤956中，i/o调用将被传递通过至文件系统。但是，如果路径在虚拟化根处或者位于其下，则映射表查找返回<vr路径，vtr路径，隔离模式>，并且控制传到步骤962以确定是指示硬隔离模式还是软隔离模式。

如果指示硬隔离模式，则在步骤964中，命名空间虚拟化组件908将在文件打开i/o调用中用<vtr路径>替换文件的文件名的<vr路径>部分。然后，在步骤966中，命名空间虚拟化组件908然后将创建包含<vr路径，vtr路径>的上下文(在下文中被称为“处置上下文”)，将其与i/o调用相关联，并且然后将i/o调用传递通过至文件系统。

然而，如果指示软隔离模式，则在步骤968中，命名空间虚拟化组件908用<vtr路径>替换文件的文件名的<vr路径>部分。然后，在步骤970中，命名空间虚拟化组件908将返回特别返回代码(例如，在一个实施例中，是“status_reparse”)，该特别返回代码将使用新路径使文件打开i/o调用重新开始。当打开回到命名空间虚拟化组件908时，命名空间虚拟化组件908将知道其已经以这种方式处理了它并且将其忽略。正是这种操作方法使得以软隔离打开的文件的“真实”名称被展示给调用者。由于打开被重新解析，因此以“真实”名称将其重新发出，因而对打开文件的查询显示“真实”名称。注意，重新解析意味着，在软隔离模式中，没有发生创建后阶段。

此时，或是执行了上述硬隔离(即，重写了名称并且允许打开操作继续进行)，或是执行了上述软隔离(即，重写了名称并且用新名称重新开始打开)。文件系统109然后将在指定路径处打开文件，然后通过文件的打开处置将调用向上传递回。在硬隔离情况下，命名空间虚拟化组件将执行打开后阶段。

在打开后阶段，在步骤972处，命名空间虚拟化组件908将包含<vr路径，vtr路径>的上下文与打开文件相关联。现在，命名空间虚拟化组件908已结束处理文件打开i/o调用。

在下文中描述了处置文件的重命名的进程的一个实施例。重命名操作包括对文件执行的、伴随有包含要应用于文件的新目的地路径名的缓冲区的重命名i/o调用，在一种情况下，该重命名i/o调用由来自容量的根的新文件名的完整路径组成。

在这种情况下，如果重命名i/o调用不在容器的上下文中，则命名空间虚拟化组件908将简单地将其传递通过至文件系统109以进行处置。否则，命名空间虚拟化组件908在映射表中查找新目的地路径名以取回<vr路径，vtr路径>。

如果映射表不包含针对新名称的映射，则将重命名i/o操作传递通过至文件系统109。

如果映射表确实包含映射，则命名空间虚拟化组件908通过用<vtr路径>替换其<vr路径>部分来修改新目的地路径名。命名空间虚拟化组件908然后发出使用经修改的目的地路径名的重命名i/o调用。当i/o调用返回到命名空间虚拟化组件908时，其完成对原始重命名i/o调用的处理。

在一个实施例中，在投影vtr的虚拟化名称的上下文中，命名空间虚拟化组件908处置返回完整路径的名称查询i/o操作。名称查询操作包括三个阶段：命名空间虚拟化组件908可以执行处理的查询前阶段、通过文件系统对名称查询i/o操作的服务阶段、以及命名空间虚拟化组件908可以执行进一步处理的查询后阶段。

在名称查询i/o操作的查询前阶段中，命名空间虚拟化组件908检查在处理文件打开i/o调用时创建的处置上下文。该处置上下文的存在指示文件是通过硬隔离映射被打开的(软隔离打开不具有处置上下文，因此它们通过设计将vtr名称“透露”给调用者)。如果不存在处置上下文，则命名空间虚拟化组件908将名称查询i/o操作传递到文件系统并且不进行进一步处理。否则，在名称查询i/o操作的查询后阶段中，命名空间虚拟化组件908使用被存储在处置上下文中的映射数据来修改文件名，使得其显得处于vr路径中。在执行这种替换之后，命名空间虚拟化组件908用新路径替换由文件系统返回的路径并且将其返回给调用者。

在实施例中，命名空间虚拟化组件908可以在名称查询操作的查询后阶段中过滤输出。例如，针对由文件系统返回的每个名称，命名空间虚拟化组件908可以在映射表中查找父目录的名称。如果父目录不在映射中，则可以返回名称。如果父目录在映射中但是其也在该映射的虚拟化目标根中，则可以返回名称。如果父目录在映射中并且其不在该映射的虚拟化目标根中，则命名空间虚拟化组件908在名称查询i/o操作的结果中抑制名称。还要注意，不论它们所处的映射是针对硬隔离还是软隔离，链路名称都可以被抑制。这样做的一个原因是因为不应该向调用者呈现调用者无法处理的名称。在一些实施方式中，将vtr名称透漏给调用者可以是可接受的，但是不能是无法被使用的名称。

优选地，在虚拟化有效时，命名空间虚拟化组件908不允许修改虚拟化根、虚拟化目标根和虚拟化例外根的任何部分的名称。在一个实施例中，命名空间虚拟化组件908可以通过维护对多个根的打开文件处置来实现此。

根据本文所描述的命名空间虚拟化技术的另一方面，取决于隔离模式，当存在命名空间虚拟化组件908映射时，可以阻止某些操作。存在可以被阻止的两大类操作，这两大类操作由操作被阻止的原因来描绘。

第一类是以下操作：可能由于这样的操作在本文所描述的类型的虚拟化系统中不应该被允许而被阻止，诸如操纵存储配额或者从底层文件系统获取文件范围。第二类是以下操作：可能由于它们是复杂难以实施的和/或将产生显著的运行时间成本而被阻止。如果遥测技术指示这些操作的省略呈现显著的用户问题，则这些操作是可以被考虑实现的操作。

注意，取决于实施方式，具有完整容量范围的特定操作可能是具有挑战性的，并且如何处置这些操作可以取决于特定实施方式。

图10图示了可以实施或者体现本文所公开的技术和解决方案的示例计算设备1012。计算设备1012可以是各种不同类型的计算设备中的任何一种，包括但不限于：计算机、个人计算机、服务器、便携式计算机、移动计算机、可穿戴计算机、膝上型计算机、平板、个人数字助理、智能电话、数字相机或者自动执行计算的任何其他机器。

计算设备1012包括处理单元1014、系统存储器1016和系统总线1018。系统总线1018将系统组件耦合至处理单元1014，系统组件包括但不限于系统存储器1016。处理单元1014可以是各种可用处理器中的任何一种。双微处理器和其他多处理器架构也可以被采用作为处理单元1014。

系统总线1018可以是若干类型的(多个)总线结构中的任何一种，包括：存储器总线或者存储器控制器、外围总线或者外部总线，和/或使用各种可用总线架构的本地总线，可用总线架构包括但不限于：工业标准架构(isa)、微信道架构(msa)、扩展isa(eisa)、智能驱动电子设备(ide)、vesa本地总线(vlb)、外围组件互连(pci)、插件总线、通用串行总线(usb)、高级图形端口(agp)、个人计算机存储卡国际协会总线(pcmcia)、火线(ieee1394)以及小型计算机系统接口(scsi)。

系统存储器1016包括易失性存储器1020和非易失性存储器1022。基本输入/输出系统(bios)被存储在非易失性存储器1022中，该基本输入/输出系统包含用以诸如在启动期间在计算设备1012内的元件之间传输信息的基本例程。作为说明而非限制，非易失性存储器1022可以包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除rom(eeprom)或者闪速存储器。易失性存储器1020包括用作外部高速缓存存储器的随机存取存储器(ram)。作为说明而非限制，ram以多种形式可用，诸如，同步ram(sram)、动态ram(dram)、同步dram(sdram)、双倍数据速率sdram(ddrsdram)、增强型sdram(esdram)、同步连接dram(sldram)和直接rambusram(drram)。

计算设备1012还可以包括可移除/不可移除、易失性/非易失性计算机可读存储介质。图10图示了例如磁盘存储装置110。磁盘存储装置110包括但不限于：比如磁盘驱动器、软盘驱动器、磁带驱动器、jaz驱动器、zip驱动器、ls-100驱动器、存储卡(诸如sd存储卡)或者记忆棒的设备。此外，磁盘存储装置110可以单独地包括存储介质或者以与其他存储介质组合的形式包括存储介质，存储介质包括但不限于：光盘驱动器，诸如光盘rom设备(cd-rom)、cd可记录驱动器(cd-r驱动器)、cd可重写驱动器(cd-rw驱动器)或者数字通用磁盘rom驱动器(dvd-rom)。为了便于将磁盘存储设备110连接至系统总线1018，通常使用可移除或者不可移除接口，诸如接口1026。

图10还描绘了充当用户与计算设备1012中所描述的基本计算资源之间的中介的软件。这种软件包括操作系统1028。可以被存储在磁盘存储装置110上的操作系统1028用于控制和分配计算设备1012的资源。应用1030利用由操作系统1028进行的、通过被存储在系统存储器1016中或者磁盘存储装置110上的程序模块1032和程序数据1034的资源管理。应该理解，本文所描述的各方面可以用各种操作系统或者操作系统的组合来实施。如进一步所示，操作系统1028包括文件系统109，该文件系统用于在磁盘存储设备110上存储和组织计算机文件及其包含的数据，以使得能够容易地查找和访问它们。

用户可以通过(多个)输入设备1036将命令或信息输入到计算设备1012中。输入设备1036包括但不限于指向设备，诸如鼠标、轨迹球、触控笔、触摸板、键盘、麦克风、操纵杆、游戏手柄、卫星天线、扫描仪、tv调谐卡、数字相机、数字摄像机、网络相机等。这些和其他输入设备经由(多个)接口端口1038通过系统总线1018连接到处理单元1014。(多个)接口端口1038包括例如串行端口、并行端口、游戏端口和通用串行总线(usb)。(多个)输出设备1040使用与(多个)输入设备1036相同类型的端口中的一些。因此，例如，usb端口可以用于向计算设备1012提供输入，并且用于将信息从计算设备1012输出至输出设备1040。提供输出适配器1042以说明在这些输出设备1040中，存在需要特别的适配器的一些输出设备1040，比如监视器、扬声器和打印机。作为说明而非限制，输出适配器1042包括提供输出设备1040与系统总线1018之间的连接方式的视频和声卡。应该注意，其他设备和/或设备系统提供输入和输出能力两者，诸如(多个)远程计算机1044。

计算设备1012可以使用与一个或多个远程计算设备(诸如(多个)远程计算设备1044)的逻辑连接在联网环境中运行。(多个)远程计算设备1044可以是个人计算机、服务器、路由器、网络pc、工作站、基于微处理器的装置、对等设备、与计算设备1012相同的另一计算设备等，并且通常包括相对于计算设备1012描述的元件中的许多或者全部元件。出于简洁的目的，仅图示了具有(多个)远程计算设备1044的存储器存储装置1046。(多个)远程计算设备1044通过网络接口1048被逻辑连接到计算设备1012，并且然后经由通信连接1050物理连接。网络接口1048包括通信网络，诸如局域网(lan)和广域网(wan)。lan技术包括光纤分布式数据接口(fddi)、铜缆分布式数据接口(cddi)、以太网、令牌环等。wan技术包括但不限于：点对点链路、电路交换网络(比如集成服务数字网络(isdn)及其变型)、分组交换网络和数字用户线(dsl)。

(多个)通信连接1050是指用于将网络接口1048连接到总线1018的硬件/软件。虽然为了图示清楚，通信连接150被示出在计算设备1012内，但是该通信连接也可以在计算设备1012外部。仅出于示例性目的，连接到网络接口1048所需的硬件/软件包括内部技术和外部技术，诸如包括常规电话级调制解调器、电缆调制解调器和dsl调制解调器的调制解调器、isdn适配器和以太网卡。

如本文所使用的，术语“组件”、“系统”、“模块”等旨在是指与计算机相关的实体，不管是硬件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是但不限于：在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。作为说明，在服务器上运行的应用和服务器都可以是组件。一个或多个组件可以驻留在进程和/或执行线程内，并且组件可以位于一个计算机上和/或分布在两个或者更多个计算机之间。

本文所描述的各方面的说明旨在提供对各个方面的结构的一般理解。说明不旨在用作对利用本文所描述的结构或者方法的设备和系统的所有元件和特征的完整描述。在阅读本公开之后，许多其他方面对于本领域的技术人员而言是显而易见的。可以利用其他方面并从本公开得出其他方面，使得可以在不脱离本公开的范围的情况下进行结构和逻辑替换和改变。因此，本公开和附图应该被视作是说明性的而不是限制性的。

结合本文所公开的各方面描述的各种说明性逻辑框、配置、模块和方法步骤或者指令可以被实施为电子硬件或者计算机软件。各种说明性组件、框、配置、模块或者步骤已经关于其功能进行了一般性描述。这种功能是被实施为硬件还是被实施为软件取决于特定应用和被施加在整个系统上的设计约束。可以针对每个特定应用以不同方式实施所描述的功能，但这种实现决策不应被解释为导致脱离本公开的范围。

结合本文所公开的各方面或其某些方面或者部分方面的各种说明性逻辑框、配置、模块和方法步骤或者指令可以以被存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式来体现，该指令在由机器(诸如计算设备)执行时执行和/或实施本文所描述的系统、方法和进程。具体地，上文描述的任何步骤、操作、或者功能可以以这种计算机可执行指令的形式来实现。计算机可读存储介质包括被实施在用于存储信息的任何非暂时性(即，有形或者物理)方法或者技术中的易失性和非易失性介质以及可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于：ram、rom、eeprom、闪速存储器或者其他存储技术、cd-rom、数字多功能光盘(dvd)或者其他光盘存储、磁盒、磁带、磁盘存储装置或者其他磁存储设备、或者可以用于存储所期望的信息并且可以由计算机访问的任何其他有形或者物理介质。

尽管已经用特定于结构特征和/或动作的语言描述了本主题，但是要理解，所附权利要求书中限定的主题并不一定限于上文描述的特定特征或者动作。相反，上文描述的特定特征和动作作为实施权利要求的示例而被公开，并且其他等同特征和动作旨在落入权利要求书的范围内。

提供对这些方面的描述以实现进行或者使用这些方面。对这些方面的各种修改将是显而易见的，并且本文定义的一般原理可以在不脱离本公开的范围的情况下应用于其他方面。因此，本公开不旨在限制于本文所示的各方面，而是根据如由以下权利要求限定的原理和新颖特征被赋予可能的最广泛的范围。