CN102239476B - 用于存储集群的共享名称空间 - Google Patents
用于存储集群的共享名称空间 Download PDFInfo
- Publication number
- CN102239476B CN102239476B CN200980143713.0A CN200980143713A CN102239476B CN 102239476 B CN102239476 B CN 102239476B CN 200980143713 A CN200980143713 A CN 200980143713A CN 102239476 B CN102239476 B CN 102239476B
- Authority
- CN
- China
- Prior art keywords
- name space
- pathname
- name
- binding
- path
- 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.)
- Expired - Fee Related
Links
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/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/164—File meta data generation
- G06F16/166—File name conversion
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)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
客户端应用使用名称空间应用来解析用来引用文件的路径名称。文件存储在固定内容集群中,通过检索唯一标识符而被访问。任何路径名称方案都被名称空间支持。名称空间应用使用绑定表来记录对象之间的绑定,所述绑定包括用于每个绑定的开始日期和终止日期以及在路径名称方案中使用的方向和分隔符数据。名称空间属性表追踪用于每个对象的属性/值,其中各对象包括每个属性的开始日期和终止日期。名称空间提供语法一般性——任何路径名称方案可被解析以识别唯一的文件。名称空间可以在应用之间共享;当一个应用修改文件/属性时,使用不同路径名称方案的另一个应用能够访问相同的数据/修改。名称空间由于用于绑定和属性的开始和终止日期而提供集群中的文件的几乎即刻的连续备份。
Description
相关申请的交叉引用
本申请要求2008年8月26日提交的、名为“RAIN存储集群中的共享名称空间(Shared namspaces in RAIN Storage Clusters)”的美国临时专利申请No.61/091,822的优先权,在此通过参引的方式将该美国临时专利申请并入。
技术领域
本发明大体上涉及名称空间。更具体地,本发明涉及在访问存储集群的客户端应用(applicaion)之间所共享的名称空间。
背景技术
现有技术的内容可寻址的存储应用将唯一的标识符返回给管理应用(或用户);作为交换,其接收并存储数字对象(如计算机文件)。一般地,这种唯一的标识符是在数字对象的内容(例如,冗长的十六进制字符串)上执行的散列函数(hash function)的结果,或者是与该数字对象相关联的唯一的随机数。然而,轮到管理应用(或用户)来决定对该唯一的标识符做什么:将其存储在哪里,如何维护该标识符,以及当存储在内容可寻址的存储器中的数字对象必须被检索时如何检索到该标识符。
当然,追踪(例如)128位的唯一的标识符对用户而言可能是困难的,并且对于习惯于使用其自己的路径名称方案的管理应用可能是有问题的。另外,各种应用可能希望使用不同的路径名称方案来查阅存储器中的数字对象,但是却不能够。此外,期望共享和访问同一数字对象的不同应用在各自管理冗长的十六进制字符串的情况下,不能做到这样。
另外,尽管存在用于备份计算机文件并恢复到计算机系统中的早先状态的很多技术,但是大多数这些技术仅仅提供离散时间下的早先状态。例如,在来自苹果公司的计算机上可用的“时间机器(TimeMachine)”特征自动地每小时进行增量备份——仅复制自最后一次备份后发生了变化的文件。但是,这种类型的备份仅仅在离散的检查点(每小时)是可用的;如果文件一直在变化的话,则不可能确定小时间的计算机系统状态。
当前,存在很多特定的名称空间,如:将主机名称映射到IP地址的DNS;将路径名称映射到各个文件的文件系统;将电子邮件地址映射到各个电子信箱的电子邮件系统;以及将统一资源定位符(URL)和统一资源标识符(URI)映射到互联网内容的Web服务器。不幸的是,这些现有技术的名称空间都没有解决上面指出的问题,并且期待改进的名称空间和技术。
发明内容
为了实现以上所述,并且根据本发明的目的,解决现有技术中的上述问题的名称空间和相关方法被公开。
本发明提供一种通用的功能以将象征性的用户可读名称映射到(例如)识别数字对象的固定内容存储器中的唯一标识符。在文件系统的上下文中,这使得用户或者管理应用能够通过象征性的名称或者通过路径名称代替通过128位的数字来查阅数字对象(例如文件)。因此,存储在固定内容存储器中的数字对象此时能够被提供更有用的象征性名称,并且能够被(例如)利用文件系统来操作。本发明确保了完全解析的路径名称不模糊,并且最多指代固定内容存储器中的单个数字对象。
本发明的名称空间通常是足够的,使其能够表示主机名称、URI、URL、分级文件名称、电子邮件地址以及几乎任何象征性名称,不论语法如何。与上面的文件系统示例相同,优选地,管理应用确保路径名称不模糊。因此,本发明提供了一种具有通用映射功能的新颖的名称空间:任何客户端应用(文件系统,电子邮件程序等)都能够利用其自己的特殊路径名称方案存储和检索数字对象而无需管理冗长的唯一标识符。名称空间支持来自不同文件系统、URL、电子邮件地址等的文件名称,所有这些都使用不同的格式用于识别数字对象,并因此提供语法一般性。
本发明的名称空间允许在任何数量的不同系统和客户端之间共享数字对象。不同类型的软件应用可以利用其自己的特殊路径名称访问存储集群中的同一数字对象,并且不仅确保了正确的数字对象在被访问,还确保了其他的软件应用能够看到对数字对象的元数据(或者数字对象本身)进行的任何改变。诸如CIFS、NFS、FTP、HTTP-Web等的大量客户端和协议被支持。
名称空间还提供将起始日期和终止日期值附到每个名称绑定和属性的功能。每个绑定或属性包括表明对象(或属性)何时开始存在和何时它被删除或改变的“起始日期”和“终止日期”。利用这些值,一旦数据被存储在固定内容RAIN集群(例如)中并且用于对象的标识符被存储在名称空间中,则不再需要手动备份。任何用户(不仅仅是管理员)都能够将时钟回拨以看到文件、文件夹或文件系统在过去的任何时刻看起来像什么。因此,不像仅仅提供在过去的离散时间处的备份功能,名称空间还提供了用于数字对象的“连续备份”的功能。
名称空间加强了共同确保不模糊的完全合格的路径名称的特定限制。在给定的名称上下文内,简单的名称仅仅能够在任何给定的时间柱身(timescape)中使用一次,以指代单个数字对象。该简单的规则足以确保给定的完全合格的路径名称将在当前或在过去的任何时刻指代最多一个数字对象。然而,给定的数字对象可能具有很多(或许是无限多的)完全合格的指代它的路径名称。
通常,任何文件系统(或者数字对象的其他集合)可被实施为固定内容存储集群(例如,独立节点的冗余阵列,或者RAIN)加上本发明的通用名称空间。因此,名称空间允许人对固定内容存储器中的存储对象分配象征性的、结构化的名称,然后在稍晚的时候通过名称检索对象。例如,构建为固定内容存储器与本发明的名称空间的组合的Linux文件系统可以用来保持分层的文件名称。
附图说明
通过参照下面结合了附图的描述,本发明及其进一步的优点可以被最佳地理解,在附图中:
图1示出了用于本发明的操作的适当计算环境。
图2示出了名称空间环境的替代视图。
图3以图形的方式表示了在对象u1的上下文中,名称“A”指代对象u2。
图4示出了对象可以具有用于多个其他对象的名称。
图5示出了图4的对象可以具有用于其他对象的名称。
图6示出了同一个对象可以具有两个或更多个名称。
图7示出了对象u1具有用于自身的名称“.”,以及u5指代其根源为“..”。
图8示出了创建新的名称空间及其根节点。
图9示出了创建新的节点。
图10示出了创建三个新的节点。
图11示出了对u5创建别名。
图12示出了对对象进行重命名。
图13示出了删除名称绑定。
图14示出了包括四个对象的简单名称图形。
图15示出了存在于名称空间内的绑定表。
图16示出了同样存在于名称空间内的属性表。
图17是在解释下面的流程图中使用的示例名称图形。
图18是流程图,其描绘了利用该示例创建名称图形的一部分。
图19是流程图,其描绘了利用不同的路径名称方案对同一对象创建另一路径。
图20示出了表示URL型路径名称的名称图形的另一示例。
图21是流程图,其描绘了如何可以删除特定的客户端应用的数字对象。
图22是流程图,其描绘了如何可以改变名称空间中的对象的属性。
图23是流程图,其描绘了如何可以检索名称空间中的对象的属性。
图24A和24B示出了适于执行本发明的实施例的计算机系统。
具体实施方式
如上所述,本发明适用于数字对象,即以数字形式表示的任何类型的信息。例如,本发明适用于信息的任何电子表示,如计算机文件、一组文件、一组文件标识符,或者数据或数据库信息的其他集合。这种数据的其他集合包括来自数字音频或视频流的帧或剪取、数码照片、扫描的纸件、声音信息、CAD/CAM设计、MRI或X射线数据、来自信息记录或文件的流、来自审查的日志记录或系统的状态日志、电子邮件存档、检查图像等。术语“计算机文件”通常在此处用来包括上述类型的信息的任何电子表示。
如本领域公知的,名称空间是被创建以保持唯一标识符或符号的逻辑分组的环境。典型地,计算机存储设备和现代计算机语言提供对名称空间的支持。存储设备可以使用目录(或者文件夹)作为名称空间。这种使用允许将具有相同名称的两个文件存储在设备上,只要它们存储在不同的目录中即可。本发明结合下面描述的固定内容存储集群使用名称空间以实现诸多优点。
图1示出了用于本发明的操作的适当环境10。本发明可以利用任何适当的计算机硬件和软件来执行;名称空间10示出了一个特定的实施例。示出的存储集群20包括任意数量的的计算机节点22-28。优选地,每个节点包括CPU、操作系统、与其他节点(或者,至少与中央路由器)的通信链路、以及任意数量的内部硬盘驱动器29。集群20一般为固定内容存储集群,这意味着其用于备份、长期存储、存档等,并且一般并不用于对计算机文件的日常访问。通常称为WORM(写入一次,读多次)存储器,这意味着一旦计算机文件或数字对象被写入到集群中,便不能改变。(当然,修改版本的计算机文件也可以存储在集群内)。集群20可以执行为独立节点的冗余阵列(RAIN),这意味着每个节点运行其自己的操作系统并作出独立的关于集群内的存储的决定。存储集群可以构建在刀片式服务器(blade)、塔式服务器(tower)、个人计算机和服务器上。可替代地,单个计算机盒内的多核处理器可以支持在每个核上运行的虚拟存储节点。在一个特定的RAIN实施例中,每个节点是1U服务器,其具有标准以太网联网的大约1兆兆字节(terabyte)的串口ATA磁盘存储容量。每个节点可以利用基于IP的LAN(局域网)、MAN(城域网)或WAN(广域网)物理地互连。
在一个实施例中,利用可从德克萨斯州的奥斯丁的Caringo公司获得的CAStor内容存储软件以及任何适当的计算机硬件来实现存储集群20。在该实施例中,一般地,计算机节点24用作在存储数字对象的节点22、26和28之间进行路由通信的路由器。在该实施例中,存储集群20是固定内容存储器,并且每个数字对象通过随机的数字(通用唯一标识符,或者称作UUID)在集群内被唯一地编址,所述随机的数字是利用随机数字生成器对该数字对象生成的。每个数字对象的内容利用散列函数进行验证。软件应用在将数字对象存储在集群中时接收UUID,并通过将该UUID提供给集群而检索该数字对象。软件应用利用标准HTTP1.1、更具体地是利用标准的称为简单内容存储协议(SCSP)的简化子集与CAStor集群进行通信(例如,通过通信链路72和74)。利用该标准接口,诸如电子邮箱、企业内容管理、健康护理应用、Web 2.0等的应用可以访问CAStor存储集群。另外,直接HTPP访问对浏览器、JAVA、Python、C++以及其他软件环境是可用的。通过内容文件服务器(CFS)软件产品可以获得对存储集群的标准文件访问,内容文件服务器(CFS)软件产品同样可以从Caringo公司获得。CFS是支持诸如CIFS、NFS、FTP、WebDAV、Macintosh、Linux等的所有主要文件协议的Linux文件系统。利用HTTP 1.1,CFS在向存储集群存储和检索计算机文件时支持这些标准文件协议。
在另一实施例中,利用可从EMC公司获得的Centera硬件和软件来实现存储集群20。在该实施例中,存储集群20是固定内容、内容可寻址的存储器,并且每个数字对象由通过散列值(通用唯一标识符,或者称作UUID)在集群内被唯一地编址,所述散列值是利用散列函数对该数字对象计算的。软件应用在将数字对象存储在集群中时接收UUID,并通过将该UUID提供给集群而检索该数字对象。
计算机30、40和50中常驻(host)使用名称空间服务器60来访问存储集群20的客户端应用或服务器软件。当然,如果需要,计算机40和50也可以在不使用名称空间服务器60的情况下访问存储集群20。在本示例中,计算机50上的软件客户端使用名称空间服务器60上可用的名称空间,以将数字对象存储在存储集群20内、管理该数字对象、并利用该客户端应用所喜欢的路径名称方案来检索该数字对象。可替代地,计算机40上的客户端应用使用计算机30上的服务器应用,以与名称空间服务器60进行交互以便数字对象存储、管理和检索。当然,客户端应用可以在名称空间所运行的同一个物理计算机上运行。
图2示出了名称空间环境的替代视图100。概念性示出的是固定内容存储集群20,其可以利用任何适当的硬件和软件来实现。优选地,集群20存储数字对象并返回唯一的标识符或通用唯一标识符,并在这种标识符被呈现给它时检索该数字对象。软件应用110、120和130在任何适当的计算机(例如计算机30-50中的一个或多个)上运行,并利用任何适当的通信链路与集群20通信。客户端应用110和130是任何适当的软件应用,其设计成通过使用名称空间160来存储、管理和检索集群20中的数字对象。客户端应用110使用软件应用120与名称空间160交互,并且客户端应用110是诸如文件系统的任何适当的客户端软件。在本实施例中,应用120是可以从Caringo公司获得的内容文件服务器软件。应用120包括SCSP接口124、FUSE开源软件模块122和将在下面描述的名称空间API 162。客户端应用130也包括名称空间API162并与名称空间160直接通信。应用130是诸如字处理、电子邮件、用户应用等的任何适当的软件应用。名称空间160是在名称空间服务器160上执行的软件模块,并且包括绑定表180、属性表190以及用符号表示的名称图形170。名称图形170不是以图形方式表示在名称空间内,而是借助于绑定表180而存在;下面将使用各种名称图形来解释本发明。
普通名称空间
用最简单的术语,名称空间是符号名称(字符串)到对象的映射。严格地来说,名称空间本身并不涉及对象自身的结构、类型或其他属性,而仅涉及对象的基本身份,该基本身份表示为对象ID(或序列号)。名称空间所要求的全部就是,名称空间中的每个独特的对象都具有其自己的对象ID。通常,给定的对象刚好具有一个对象ID,尽管该对象可以具有多个指代它的名称绑定(name binding)。除了根之外,名称空间中的每个简单的名称都在某一对象的上下文中来理解。每个对象可用作对于附加名称的命名上下文,并且给定上下文内的所有名称限制为彼此不同。名称空间在逻辑上是三元组(对象1,名称,对象2),这意味着在对象1的上下文中,给定的名称指代对象2。这被称作名称绑定。
一种使名称空间中的名称映射的全体形象化的方式是将它们想成有向图。最简单的可能的名称空间是两个不同的对象之间的命名关系。当看成有向图时,可能看起来像图3一样。该图是以下含义的图形化表示:在对象u1的上下文中,名称“A”指代对象u2。对象可以具有用于多个其他对象的名称,如图4所示。并且,这些对象可以具有用于其他对象的名称,如图5所示。名称空间图形中的节点称作“对象”,并且如前面所提及的,边(edge)称作“名称绑定”,或者简单地称作“绑定”。
这在一开始看起来像传统的文件系统目录分级,并且这确实是名称空间的最重要的应用,允许文件系统存储和解析文件路径名称。然而,注意到文件系统目录结构并不是严格分级的。如图6所示,存在允许同一个对象具有两个或更多个名称的硬链接和软链接。在该名称空间内,对象u4在u3的上下文中命名为“C”,但是在u6的上下文中却命名为“A”。注意到,各个名称(例如,“A”)不需要在整个名称空间上是独特的。在一个上下文内,所有的名称是不同的。在名称空间内,如在文件系统内,在图形中甚至允许循环。例如,对象u1具有用于自身的名称“.”,并且u5将其根源称为联想起Unix惯例(convention)的“..”,如图7所示。
名称空间具有单个的、独特的根节点,所有不合格的名称都被从该节点解析。这连同某种语法分隔符一起允许使用完全合格的路径名称来识别名称空间图形中的任何对象。假定u1是图7的上述图形中的根节点,并且“/”是分隔符,则下面的路径名称将以如下形式解析:B/D=>u5;B/C=>u4;C/A=>u4;./././B/D/../C=>u4。
不同的客户端应用可以使用名称空间图形的不同部分。例如,文件系统的实现可以安装在“filesystems/linux/app1”或“filesystems/windows/app2”处开始的文件系统。
名称空间应用编程接口
可以由一个或多个计算机服务器以允许被多个客户端应用并发访问的形式来实现名称空间。为了方便客户端应用,提供名称空间锁(见下文)。然而,这些锁对于名称空间本身完全是可选的,因为上面列出的原始名称空间操作中的每一个都一直保持总名称空间的ACID属性(原子性、一致性、隔离和耐久性)。在下面的API定义中,应当理解,所有的路径参数都是完全合格的路径名称,其源自名称空间的根节点。简单的名称是给定上下文中的对象的名称。通过使用沿着路径的各种上下文分隔符(separator)和路径目录(pathdir),由简单的名称构建路径名称。下面的原子(atomic)函数通过名称空间来执行。
API写入操作
namespace(name[,separator][,pathdir])
该函数构建了新的名称空间和称为名称的根节点。在进行解析以及构建路径名称时,可以缺省的形式使用可选的参数“separator”和“pathdir”。(参见下文对路径名称的描述。)如果没有提供分隔符或路径遍历(traversal)方向参数,则名称空间将默认使用分隔符“/”和路径遍历方向“向左”。
bind(contextPath,name[,separator][,pathdir])
该函数在给定上下文中创建新的名称绑定。如果contextPath不存在,(contextPath,name)对已经存在于当前时间柱身(timescape)中,或者如果名称含有用于该上下文的分隔符,该函数失败。
unbind(path)
该函数删除当前时间柱身中的名称绑定。如果path不存在,则该函数失败。
alias(path,contextPath,name)
该函数将绑定拷贝成一个新的。任一个的进一步改变是完全独立的。如果源路径不存在、上下文不存在、名称已经存在于上下文中、该名称含有用于该上下文的分隔符、或者如果源路径和目标路径处于不同的名称空间中,则该函数失败。
link(path,contextPath,name)
该函数创建到已有对象的链接。其具有与Unix硬链接相同的语法。对任何链接的任何将来的修改(例如,函数setAttributes)也将适用于所有的链接。如果源路径不存在、上下文不存在、名称已经存在于上下文中、该名称含有用于该上下文的分隔符、或者如果源路径和目标路径处于不同的名称空间中,则该函数失败。
rebind(path,contextPath,name)
该函数对已有的名称绑定重新命名(移动)。这本质上是源路径被解除绑定(unbind)之前的链接。历史在重新绑定过程中被保持。如果源路径不存在、上下文不存在、名称已经存在于上下文中、该名称含有用于该上下文的分隔符、或者如果源路径和目标路径处于不同的名称空间中,则该函数失败。
setAttribute(path,key,value[,collectable])
该函数设置或创建用于绑定的属性键/值对。如果可选的布尔参数“collectable”为真(默认为假),则垃圾收集器将通知应用何时这些属性不再是可访问的(见下面的论述)。如果路径不存在,则该函数失败。
setAttributes(path,pairs)
该函数设置或创建用于绑定的多个属性键/值对。如果路径(path)不存在,则该函数失败。
deleteAttributes(path,key)
如果属性键/值对存在的话,则该函数从绑定中删除该属性键/值对。如果路径(path)不存在,则该函数失败。
API读操作
resolve(path)[,timescape])=>Boolean
该函数解析路径名称并返回其是否存在于该timescape(时间柱身)中。“timescape”参数是可选的,并且如果省略的话,将通过搜索在当前时间活动的所有绑定来解析路径名称。也就是说,解析函数对当前的时间柱身是默认的。另一方面,如果向timescape参数提供过去的日期/时间值,那么路径解析将在给定的日期和时间处发生,并且仅在给定的路径存在于过去的该时刻的情况下,该函数才将返回真。
list(path[,timescape][,offset][,limit]=>{names}
该函数返回上下文中的所有名称绑定。从语法意义上,这意味着返回前缀是“path”的所有简单名称。如果使用“timescape”参数,那么所返回的名称是在给定的日期和时间存在的名称。可选的参数“offset”和“limit”用来访问可管理的“块”中可能的大的名称列表。例如,如果offset=1000并且limit=100,那么程序将返回以第1000个开始的多达100个名称。如果路径不存在,则该函数将失效。
history(path[,timescape])=>{changes}
该函数返回在该时间柱身(timescape)中由路径(path)命名的对象的修改历史。历史总是完整的历史,所以其通常包括在时间柱身(timescape)之前和之后进行的修改(如果有修改的话)。可选的参数“offset”和“limit”是如上所述的那样。如果路径(path)不存在,则该函数失败。
getAttribute(path,key[,timescape])=>{value}
该函数返回该时间柱身(timescape)中用于给定路径(path)的给定键的属性值。
getAttribute(path[,prefix][,timescape][,offset][,limit])=>{pairs}
该函数返回该时间柱身(timescape)中给定路径(path)的所有属性。如果提供了prefix字符串,则仅仅将其键以该前缀开始的那些属性返回。可选的参数offset和limit如上所述。
getAttributeKeys(path[,timescape][,offset][,limit])=>{keys}
该函数返回该时间柱身(timescape)中给定路径(path)的所有属性的键。可选的参数offset和limit如上所述。
getLinkCount(path,[,timescape]=>count
该函数返回该时间柱身(timescape)中由路径(path)命名的对象的链接的数量。如果路径(path)不存在,则该函数失败。
API锁定操作
Lock(path,type,pid,timeout)
该函数需要由路径(path)指定的名称上的名称空间锁。type和pid参数可以是任何字符串。它们旨在表示锁定类型(例如,“写”)和获取器的过程识别。如果锁没有被明确地因超时的秒数而释放,名称空间将自动地过期(释放)锁定。如果锁已经存在并且pid为同一个,则可以调整超时(timeout)值(如果期望的话,可以进行处理以改变其自己的锁定的到期时间)。如果路径(path)不存在或者在路径(path)上存在相同类型(type)但是具有不同pid的已有的锁,则该函数失败。
unlock(path,type,pid)
该函数释放由路径(path)所指定的名称上的名称空间锁。如果路径(path)不存在、不存在具有给定路径(path)和类型的已有的锁、或者如果锁属于不同的pid,那么该函数失败。
API垃圾收集
garbage(namespace[,timescape][,offset][,limit]=>{pairs}
该函数返回在过去、当前或将来不再能够经由名称空间(namespace)中的任何名称访问的可收集属性(见上文关于setAttribute的论述)键/值对的列表。可选的参数offset和limit如上所述。如果名称空间(namespace)不存在,则该函数失败。
名称空间普通示例
为了进一步示出上面的名称绑定方法的预期的语法,这里示出了名称空间调用的序列以及由其产生的名称图形变形。
图8示出了利用命令(call):namespace(“file”),创建新的名称空间及其根节点。
图9示出了利用命令:bind(“file”,“home”,“/”,“left”)在根上下文中创建名称为“home(出发点)”的新的节点。
图10示出了利用命令:bind((“file:home”,“jim”)),bind((“file:home”,“laura”))以及bind((“file:home/jim”,“foo.txt”)),创建三个新的节点。
图11示出了利用命令:alias((“file:home/jim”,“foo.txt”)),(“file:home/laura”,“bar.txt”))”生成u5的别名。
图12示出了利用命令:rebind(“file:home/jim/foo.txt”,“file:home/laura”,“foo.txt”)),将“foo.txt”重命名(移动)到Laura的上下文。
图13示出了利用命令:unbind(“file:home/laura/bar.txt”),删除“bar.txt”名称绑定。
日期功效
在上面的名称空间写操作部分中列出的所有操作都在名称空间的当前状态(“当前时间柱身”)上运行,名称空间读操作的默认变型也是如此。当对名称空间进行修改时,每个名称绑定的状态在被以修改日期和时间(“终止日期”)进行时间标记之后,被保存。读操作也可以被给定时间柱身参数、过去的日期/时间值,以便一旦名称绑定出现便访问关于它们的信息。每个名称绑定都具有开始日期,并且可能还具有终止日期,该开始日期是绑定首次变为有效的日期和时间,该终止日期是绑定被改变或删除的日期和时间。
例如,假设在时间t1,在对象u1的上下文中创建用于“green(绿)”的新的名称绑定。就其而言,该名称绑定可能看起来是:
(u1,“green”,u2,start=t1)
任何改变绑定的名称空间操作都将产生其一份新的拷贝,并填写该拷贝的终止日期,从而制成旧的绑定的历史记录。例如,假设上述绑定在时间t2被利用bind (“green”,u3)更新。将产生新的绑定,并且原始的绑定将如bind( )操作中所指示地那样被修改。结果产生两个绑定,一个是当前的,一个是历史的。
(u1,“green”,u2,start=t1,end=t2)
(u1,“green”,u3,start=t2)
此时,假设在时间t3利用rebind(“green”,“blue”)进一步修改新的绑定,以改变其名称。第二历史绑定将被创建,以记录该事件,并且原始的绑定将因操作命令再次被修改。
(u1,“green”,u2,start=t1,end=t2)
(u1,“green”,u3,start=t2,end=t3)
(u1,“green”,u3,start=t3)
优选的是,历史绑定是原始绑定的拷贝,而原始绑定根据名称空间操作被修改。该技术允许我们产生名称绑定的修改历史(见下面)。
如果可选的“datatime(日期时间)”参数被包括,则诸如list()的名称空间读操作能够获取关于历史名称绑定的信息。例如,命令list(“home/jim”,datetime=1)将使源自start≥t并且end<t的home/jim的所有名称绑定返回。已经被“end-dated(标记终止日期)”的历史绑定将被名称空间保留一段可配置的时期,然后它们将被利用垃圾收集而永久地删除。实际上,利用该机制在时间上追溯回去是可能的,但是仅仅能到特定的点。
修改历史
除了能够在名称绑定存在于过去时看到名称绑定之外,还必须看到对名称进行的所有改变,例如,恢复已经被更新若干次并从一个子目录移动到另一个子目录的文档的先前修订。history()方法能够做到这一点。当利用create()、alias()、或link()创建新的名称绑定时,唯一的绑定身份被分配给该名称绑定,该绑定身份被称为“绑定唯一标识符”或buid。随后利用bind()(更新)、rebind()(重新命名)、unbind()(删除)、或setAttributes()对名称绑定进行的改变将使绑定保留原始buid,同时新的、标记终止日期的、历史的绑定也将使用同样的buid。history()方法简单地返回过去、当前、或将来与给定的名称具有相同buid的所有绑定。
名称空间锁定
严格地来说,名称空间不需要锁定机制,以便确保名称绑定的一致性,因为所有的操作都是原子的和无状态的。然而,名称空间提供普通的锁定机制以支持客户端应用(特别是CFS应用),这些客户端应用确实出于某些目的而需要锁定名称绑定,例如,为了执行写锁定,以使两个过程不能够同时使同一个文件打开以进行写入。名称空间本身并不给这些锁分配任何含义,即,所有的名称空间操作始终是对任何客户可用的。锁定语法和加强严格地是名称空间的客户端应用之间的自愿合作的问题。
名称空间的具体示例
图14-16示出了名称空间内的名称图形及其表示的简单、具体的示例。图14示出了简单的名称图形310,其包括四个对象:根1和对象2、3和4。名称A、B、X和Y将这些对象链接起来并提供通向对象4的两条路径(假设分隔符“/”被使用):路径/B/X,和路径/A/Y。这种简单的名称图形表示例如用于同一计算机文件的两个不同的文件名称,即/B/X和/A/Y。假设对象4包括是用于计算机文件的通用唯一标识符的属性,那么可以通过遍历名称图形(沿任一方向)、从对象4取回UUID以及然后将UUID传递给存储集群而从存储集群20中检索计算机文件。名称图形中的每个对象被分配唯一的序列号,例如数字1-4。这些序列号由名称空间分配并且仅在内部使用。尽管名称空间可以包括除了在唯一的根之外未彼此连接的多个不同的名称图形,但是序列号在整个名称空间内是唯一的。
图15示出了存在于名称空间160内的绑定表320。绑定表是通过其来表示和遍历名称图形及其对象的装置;绑定表320通过在每行中列出绑定来实现名称图形310。列322包括对象的序列号,并且提供对于该绑定的上下文。列324是分配给绑定的名称。列326是被应用该名称的对象的序列号。列328是绑定首次被创建的开始日期和时间。列330是绑定被删除的终止日期和时间。向下近似到秒地计算并存储开始时间和终止时间。当然,取决于CPU和所涉及的操作系统,如果需要,以细分得多的粒度计算和存储时间是可能的,例如十分之一秒或百分之一秒。以这种方式,为了提供自动连续备份功能,名称空间、其对象、以及最终由名称空间表示的数字对象的状态的连续记录可以被维护并且被查阅。
列332指代整个路径名称的上下文中的名称所使用的路径遍历方向。例如,文件系统路径名称通常是一致的,因为随着名称从左遍历到右,计算机文件的位置变的更具体(例如,“出发点(home)”之后是“文档(documents)”,“文档(documents)”之后是“brochure.pdf”)。随着名称从右遍历到左,其他路径名称方案变的更具体,例如johndoecompanyX.com。并且,诸如URL的一些路径名称组合两者的位。因此,绑定表中的每个绑定行的“方向”区域允许名称空间指定“名称”在哪个方向上变的更具体。例如,在名称空间中所表示的典型的文件名称将都具有“左”方向,因为它们在从左遍历到右时变的更具体。相反,电子邮件地址将具有“右”方向。诸如URL的指代数字对象的路径名称可以具有“左”和“右”两者的绑定的组合。
列334指示在特定路径名称方案中的名称之间使用的分隔符。例如,苹果文件名称一般使用“/”作为用于计算机文件的路径名称中的名称之间的分隔符。其他常用的分隔符是:在Windows文件系统中使用的“\”,在某些苹果Macintosh文件系统中使用的“:”,在IP地址中使用并用来描绘顶级域名的“.”,在电子邮件地址中使用的“”,用来使电话号码部分分开的“-”,以及其他分隔符。绑定行中的分隔符指的是紧邻在数字对象的路径名称中的名称前面或紧邻在该名称后面所使用的分隔符,这取决于分隔符的方向。
在绑定表中不存在另外的相关信息。
绑定表320的第一行表示绑定(bind)函数已经被用来利用名称“A”将对象1绑定于对象2。绑定在特定的日期于上午8点34分16秒创建。尽管为了方便说明没有将日期显示在该列中,但是一般地,列328包括日期和向下几乎到秒的时间。如果当绑定(bind)函数被调用时对象2不存在,那么在该时创建对象。第二和第三行示出了对绑定(bind)的相似调用的结果。第四行示出了将对象2链接到预先存在的对象4的链接函数命令的结果。用于“终止日期”列的值被设置为将来的遥远时间(例如4,000年),以表示绑定仍然存在。因此,能够看到随着对象和链接被添加到名称空间,绑定表中的行对于特定的名称空间而被建立起来。如将在下面解释的,客户端应用然后可以通过引用绑定表中自己的绑定使用已有的名称图形,以利用大量不同路径名称方案中的任一种来从存储集群20中检索数字对象。
图16示出了同样存在于名称空间160内的属性表360。由于绑定表仅仅是表示名称图形的一行接一行的绑定,所以属性表只是一行接一行的属性。每个行识别名称图形中的特定对象的特定属性,并且提供值。例如,第一行表示对象4包括UUID并且用于该标识符的值是“F84B91CD”,该值是十六进制数,其表示识别唯一地位于存储集群20内的数字对象的随机数。当然,用于识别存储集群中的数字对象的对象的唯一标识符可以具有适于存储集群的执行的任何值。例如,该唯一的标识符可以是对于数字对象而随机生成的数,可以是由应用于数字对象的内容的散列函数产生的散列值,或者可以是由中央机构(central authority)分配的某种其他的唯一标识符。后者的例子包括国际电话号码、使用IPv4或IPv6的IP地址、完全合格的域地址、纬度/经度位置、笛卡尔和其他坐标系统中的坐标、以及很多其他的标识符。
在当前的实施例中,UUID所命名的属性是CAStor软件使用的通用唯一标识符,并且其值是随机生成的具有128位的数字。第二行指示对象4具有称为“模式”的属性,并且其值是存储在表的行366中的值。
诸如“用户标识符”和“组标识符”的其他属性可用来存储关于数字对象的任意元数据。
与绑定表一样,属性表提供对于每个对象的每个属性的开始日期和终止日期。这些日期允许与上面对于绑定所描述的相同的时间柱身功能。特别地,名称空间能够提供完整的一组属性以及在过去的某一任意日期它们对于任何数字对象的值。对象的属性由客户端应用确定,并且任何属性和值都可以根据客户端应用的需要而存储。例如,属性可以表示与存储集群20中的数字对象相关联的元数据。如图16所示,有用的属性是允许客户端应用从存储集群检索数字对象的通用的唯一标识符。
名称空间的语法一般性
本发明的一个实施例将数字对象存储在存储集群中,并创建名称空间中的表示,该表示考虑了客户端应用所使用的优选路径名称方案。如上所述,客户端应用使用多种路径名称方案用于指代数字对象。URL典型地是“www.company.com/folder/blue”的形式(概括为该路径内的不同方向的具体流)。URI是“ftp://”或“file://home/Fred/file.txt”的形式。IP地址具有“192.168.1.1”的形式。苹果计算机具有“home:green:blue”的形式的文件名,而运行Microsoft操作系统的计算机具有“\home\green\blue”的形式的文件名。因此,路径名称方案是不同的,因为它们使用不同的语法,但是是相似的,因为它们使用特定的分隔符来将路径名称内的名称分开,并且从一般到具体、从具体到一般始终一致地前进,或者使用两者可预测的混合。因此,本发明表示名称空间内的这些名称、分隔符以及特异性(specificity)的方向,以允许语法一般性。换句话说,任何客户端应用,无论其使用哪个路径名称方案,都将被允许使用完全不同的路径名称方案存储、管理和检索另一个客户端应用所参考的同一个数字对象。
图17是在解释下面的流程图中使用的示例性名称图形410。如图所示,该图形包括经由对象1、2、3和4的第一路径和经由对象1、5、6和4的第二路径。两个路径都终止在对象4处,对象4优选包括保持用于存储集群20中的特定数字对象的通用独特标识符的属性。在本示例中,数字对象是保持用于个人John的配置信息的文件“myemail.txt”。第一路径表示例如特定文件的Unix路径名称,而第二个路径表示典型的电子邮件地址路径名称。一个或多个客户端应用可以希望使用不同的路径名称存储或访问文件。
图18是描绘利用该示例创建一部分名称图形的流程图。在步骤422中,任何适当的客户端应用(例如,客户端应用110)使用内容文件服务器(Content File Server)应用120以便在名称空间服务器60上创建名称空间。当然,客户端应用可以代替使用CFS而直接访问名称空间服务器。根对象1被创建;此时,绑定表和属性表两者都是空白的。创建名称空间命令也可以在名称空间模块安装在名称空间服务器上时由安装者启动。在步骤426中,客户端应用请求CFS将新的文件存储在存储集群中并将其表示存储在名称空间中。在本示例中,文件的路径名称是“home/John/myemail.txt”。优选地,客户端应用解析整个路径名称,以将路径名称的每个部分(以增加特异性的方式)、每个名称前面的分隔符以及要存储的计算机文件的实际内容提供给CFS。
在步骤430中,CFS(或者在直接访问名称空间的情况下是客户端应用)利用绑定(bind)函数和第一名称“home”、以及适当的分隔符和方向调用名称空间,以创建绑定452。此时还创建新的对象2。作为响应,名称空间创建绑定表中的行,以表示该新的绑定。类似地,步骤434和438利用名称“John”和“myemial.txt”调用bind函数,以分别创建对象3和4以及绑定454和456。此时,已经利用对象1、2、3和4创建了名称图形,其中对象4唯一地表示数字对象“myemail.txt”。接下来,步骤442将该文件写入存储集群中,并且存储集群返回唯一标识符或通用唯一标识符。最后,在步骤446中,CFS创建属性“UUID”(例如),并将该属性设为等于所返回的用于名称空间410中的对象4的唯一标识符。如前面所提及的,客户端应用可以对任何对象创建任何适当的属性,尽管这些属性都不是所需要的。结果,名称空间此时向对象4提供使用特定路径名称方案的路径,其中对象4保持用于存储在存储集群20中的计算机文件的唯一标识符。
图19是流程图,描绘了使用不同路径名称方案创建到同一对象4的另一路径。在本示例中,使用不同的路径名称方案的不同客户端应用(如客户端应用130)希望访问先前已经存储在集群中并表示在名称空间中的同一计算机文件“home/John/myemail.txt”。
在步骤462中,客户端应用130请求名称空间使用路径名称“Johncompany.com”创建新的路径,然后该路径名称在步骤474中被链接到已经存在的对象。名称空间链接函数将新形成的路径名称“Johncompany.com”链接到当前由路径“home/John/myemail.txt”命名的完全相同的对象,该对象在本示例中为对象4。名称空间链接在构造和使用方面与Unix类文件系统中的“硬链接”相似。
优选地,客户端应用解析整个路径名称,以将路径名称的每个部分(以增加的特异性方式)和每个名称前面的分隔符提供给名称空间。在本示例中,客户端应用解析路径名称以获得如下的增加的特异性的名称:“com”、“company”、和“John”。
在步骤466中,客户端应用利用绑定(bind)函数和第一名称“com”以及适当的分隔符和方向调用名称空间,以创建绑定482。新的对象5也在此时创建。作为响应,名称空间创建绑定表中的行,以表示该新的绑定。类似地,步骤470利用名称“company”调用绑定(bind)函数,以创建对象6和绑定484。接下来,客户端应用调用链接(link)函数以创建绑定486,该链接(link)函数作为自变量穿过到对象4的已有路径、到对象6的当前路径、以及名称“John”。此时,已经利用对象1、5、6和4创建了新的路径;对象4仍借助保持属性UUID及其值的该对象来唯一地表示数字对象“myemial.txt”。因此,两个不同的客户端应用此时各自具有通向名称空间内的同一对象的使用不同路径名称方案的不同路径。该对象4保持属性UUID,属性UUID提供用于存储集群内的数字对象的唯一标识符。
当然,一旦已经如上所述地构建了名称空间(并且一个或多个路径名称指向保持用于存储集群中的特定文件的独特唯一标识符的特定对象),则任何客户端应用都能够使用多种路径名称中的任何一个检索该唯一的标识符。一旦从名称空间检索到该独特的标识符,则其可以被用来访问存储集群中的特定数字对象。例如,希望检索计算机文件“myemail.txt”的Unix客户端应用可以通过调用如下的名称空间函数来做到这样:
GetAttr(UUID,/home/John/myemail.txt)
该“获取属性”函数将基于所提供的Unix风格的路径名称返回通用的唯一标识符。然后UUID可以被用来从存储集群检索计算机文件。为了执行该函数调用,名称空间接收Unix路径名称并沿着名称图形410的左手侧向下行进(利用绑定表中的信息),直至到达对象4。然后,其访问用于对象4的属性表,以检索用于属性名称“UUID”的值。
此时,考虑希望检索同一计算机文件但是使用其自己的不同路径名称的电子邮件程序客户端应用。其将如下调用名称空间函数:
GetAttr(UUID,Johncompany.com)
注意到,电子邮件程序被允许使用其自己的路径名称方案,但是最终结果是其将检索到同一个通用唯一标识符,并且然后将能够从存储集群检索到完全相同的计算机文件。为了执行该函数调用,名称空间接收电子邮件路径名称并沿着名称图形410的右手侧向下行进(利用绑定表中的信息),直至到达对象4。然后,其访问用于对象4的属性表,以检索属性名称“UUID”的值。
图20示出了表示URL型路径名称的名称图形的另一示例。考虑识别存储在特定位置的特定文件的下面的URL:http://www.company.com/green/blue.pdf。该特定的路径名称方案并不一致地从左到右或从右到左地从一般流向具体;相反,流动在路径名称内改变方向。希望存储数字对象“blue.pdf”的客户端应用将对上述URL进行解析,并对名称空间函数bind进行渐进的调用,该函数随着每次调用而经过更多来自URL的具体名称。因此,图20象征性地示出了所生成的从最广义的名称“com”向下一直到最具体的“blue.pdf”的名称空间的名称图形。绑定函数使用使用参数“separator”和“direction”来将该信息存储在绑定表中。该信息然后在任何客户端应用希望检索数字对象“blue.pdf”时从绑定表被使用。如上所述,客户端应用仅仅将URL“http://www.company.com/green/blue.pdf”传递到名称空间,名称空间然后使用绑定表以及方向和分隔符信息,以便遍历该名称图形,到达对象6并检索对应于文件“blue.pdf”的UUID。
因此,名称空间能够获取客户端应用所使用的任何类型的整个路径名称,并且只要根据该路径名称方案的路径之前已经被表示在名称空间中,则名称空间将返回与任何特定对象相关联的任何期望的属性。在本示例中,客户端应用能够使用其自己的路径名称方案,以指代存储在存储集群中的同一数字对象。
在应用之间共享的名称空间
如上所述,诸如客户端应用110-130的任何客户端应用都可以利用其自己的特定路径名称方案访问名称空间,并仍能确保每个路径指代同一数字对象。在图17的示例中,来自两个不同的客户端应用的两个不同路径名称都指向对象4,对象4保持例如具有识别存储集群20内的单个数字对象的通用唯一标识符值的UUID的属性。属性表360保持用于所有对象的所有属性,并且对任何希望读或设置特定对象的属性的客户端应用都是可访问的,名称空间及其对象和属性在所有客户端应用之间基本上是共享的。改变用于特定对象的特定属性的客户端应用将使该改变同样可被任何其他客户端应用看到。在此处所使用的示例中,当对象表示存储集群中的数字对象时(例如,图17的对象4保持用于存储在存储集群中的文件“myemail.txt”的UUID),这意味着数字对象和数字对象的改变(以及它们的元数据)同样在所有客户端应用之间共享。
例如,如果一个客户端应用希望修改存储在存储集群中的计算机文件并且让所有其他的客户端应用引用该修改的文件,则可以这样做。客户端应用首先修改计算机文件,将其存储在存储集群中,接收新的UUID,然后执行下面的名称空间函数:SetAttr(UUID,<path>,new UUID)。结果是,该设置属性的函数将找到由“path”指定的特定对象(例如,经由左手路径名称找到对象4),并且改变属性UUID为新的UUID值。因此,引用对象4的任何其他客户端应用(例如,使用右手路径名称的客户端应用)都将在访问UUID属性时检索该新的UUID值,并将能够检索存储集群中的修改计算机文件。
当然,对特定对象改变的任何属性都将被访问该对象的客户端应用中的任何一个看到。客户端应用可以通过改变例如对象4的特定属性来改变用于存储在存储集群中的特定数字对象的元数据。客户端应用可以改变的元数据的示例包括:修改日期、允许、访问控制列表、对象大小、关键词等。
名称空间的连续备份特征
如上所述,本发明的名称空间的执行导致实际上对存储在存储集群内的数字对象的连续备份,以及对存储在名称空间的属性表中的它们的相关属性中任何一个的连续备份。当然,存储集群必须确保数字对象的所有版本都保留一段时期,在这段时期内希望进行连续的备份,并且名称空间必须确保属性及其值同样在这段时期内也被保留。名称空间能够利用特定函数调用与使用绑定表和属性表的开始日期和终止日期字段的组合来实现连续备份特征。
图21是流程图,描绘了可以如何删除用于特定客户端应用的数字对象。考虑图17的名称图形示例,假设个人“John”已经离开了公司并且希望删除他的数据,包括存在于存储集群内的他的电子邮件配置文件“myemial.txt”。在步骤504中,适当的客户端应用(如公司的电子邮件程序)确定引用该特定文件的路径名称是Johncompany.com(利用图19的示例预先存储的)。客户端应用然后确定名称“John”应当从其当前指向的任何对象中解除绑定。在实际中将对象4从名称空间移除是并不适当的,因为有可能另一个客户端应用正在使用不同的路径名称来引用该对象(在本示例中是真的)。并且,即使没有其他的客户端应用涉及该对象,将对象4移除将导致指示配置文件“myemail.txt”在过去的特定时间实际存在过的信息丢失。
接下来,在步骤508中,客户端应用利用unbind函数调用名称空间,该unbind函数传递上下文、对象6、以及要移除“John”的绑定的名称。为了表明文件已经被“删除”(至少就电子邮件程序而言),在步骤512中,名称空间仅仅修改绑定表中的行,以提供绑定“John”的“终止日期”。例如,在删除之前,绑定表中的行可能看起来是这样:“6 John 4 1/1/2009:08:36:00 4,000”。该行表示绑定486创建于2009年1月1日,且在创建时,其具有大约无限远的终止日期(为了清楚起见,已经去掉了方向和分隔符字段)。假设客户端应用在该日的上午10点删除配置文件,则绑定行在删除之后将看起来如下:“6 John 4 1/1/2009:08:36:001/1/2009:10:00:00”。注意到,所有所发生的是上午10点的终止日期已经被提供给该绑定。该绑定实际上没有从名称空间中移除;对象4和配置文件分别继续存在于名称空间和存储集群中。因此,具有到对象4(并因此到配置文件)的路径任何客户端应用都将继续这样做。先前使用路径名称“Johncompany.com”的电子邮件程序将不能够访问配置文件,因为绑定486已经通过在绑定表中提供终止日期而被有效地移除。
当访问名称空间中的对象和绑定时,名称空间将假定当前时间的时间,并将不会辨认出当前时间未落在开始日期和终止日期内的任何绑定。例如,如果电子邮件程序试图在2009年1月1日的上午11点访问配置文件,那么这种访问将失败,因为上午11点是在用于该绑定的上午10点的终止日期时间之后。相比之下,电子邮件程序可以当其在过去存在时访问配置文件,只要其提供落在用于绑定486的开始日期和终止日期之间的过去时间参数即可。名称空间简单地将输入时间参数与开始日期和终止日期作比较。默认地,名称空间假设该时间参数是当前时间。当然,如果电子邮件程序试图通过提供2009年1月1日上午8点36分之前的时间来访问在过去的配置文件,那么这种访问也将失败,因为名称空间将确定所提供的在过去时间在用于该特定绑定的开始日期时间之前。
注意到,在图21的过程中,用于存储在属性表中的对象4的属性不改变,因为仅仅是绑定486正被提供绑定表中的终止日期;对象4的属性都不在被改变或删除。在该过程期间,属性不改变或删除,因为另一个客户端应用可能正在使用对象以及因为该属性及其值应当被保留以便对其在过去存在时的配置文件的历史访问。
图22是流程图,描绘了可以如何改变名称空间中的对象的属性。在本示例中,即使属性可以改变,该属性的历史值也被保留。例如,如果计算机文件在存储集群中被客户端应用修改,那么理想的是,该计算机文件的原始版本不仅被存储集群保留,而且还可被任何希望看到其在过去存在时的该文件的客户端应用访问。因此,允许用于UUID属性的旧值被名称空间保留(在属性表中)是理想的。
在步骤520中,客户端应用确定特定的计算机文件和其希望改变的该文件的属性。优选地,客户端应用确定引用名称空间中的该文件的路径名称(预先设置)和其希望改变的属性。在一个示例中,客户仅仅希望修改用于特定计算机文件的元数据属性而不改变文件本身。或者,客户已经修改了计算机文件并接收到来自存储集群的引用文件的新版本的新的UUID。因此,该新的UUID必须被用来替换表示计算机文件的名称空间中的对象的旧的UUID属性。
在步骤524中,客户端应用以设置属性的函数来调用名称空间,该设置属性的函数传递要改变的属性的名称(例如UUID)、到名称空间中的期望对象的路径名称、以及要改变的属性的新值。在步骤528中,名称空间试图利用所提供的路径名称找到名称空间中的对象。有可能的是,对象并不存在(从未存在过或者已经被删除)。如果不存在,那么在步骤532中,该过程终止。如果对象被找到,那么在步骤536中,对于对应于该特定对象和已经在设置属性的函数调用中被传递的属性名称的行,对属性表进行搜索。如果当前时间没落在用于该特定属性(属性不是“活”)的开始日期和终止日期的范围之内,那么过程终止,因为用于该对象的属性之前已经被删除并且不能被改变。
一旦找到,则在步骤540中,“活”属性行被复制,以产生用于该同一对象和属性表中的属性的相同的新的行。在步骤544中,用于原始行的终止日期被提供(使用当前时间),该终止日期表明该属性的旧值已经存在过,并且一直存在到其被改变的当前时间。在步骤548中,用于新的行(其具有用于属性的新值)的开始日期被设为当前时间,并且终止日期被设为无限值。接下来,在步骤552中,用于该属性的新值被插入到用于新的行的值字段中。因此,该属性的旧值被保留在属性表中,并且利用开始日期和终止日期,该属性的旧值的存在时间被精确地反映在该原始行中。新的属性值被反映在属性表中的其自己的行中,其中开始日期表示其何时开始存在。以这种方式,客户端应用可以修改存储集群中的文件并改变用于名称空间中的相应对象的UUID属性,从而表明新的文件已经在特定时间开始存在,并且如果客户端应用希望看到其被改变之前的时间的文件的原始版本,则仍然保留UUID的旧值。换句话说,属性的旧的版本不被删除,而是被以适当的开始日期和终止日期保留。
图23是流程图,描绘了可以如何检索名称空间中的对象的属性。在本示例中,尽管属性可能已经改变,但是其历史值可以被检索。例如,如果计算机文件在存储集群中被客户端应用修改,那么该计算机文件的原始版本被希望看到其在过去存在时的该文件的任何客户端应用检索到是有可能的。
在步骤560中,客户端应用确定特定的计算机文件和其希望检索的该文件的属性。优选地,客户端应用确定引用名称空间中的(预先设定的)该文件的路径名称和其希望的属性。在一个示例中,客户端仅仅希望检索特定计算机文件的元数据属性而不检索文件本身。或者,客户端希望检索文件在过去的特定时间点存在时的文件版本并将需要检索该旧版本的UUID属性以从存储集群检索该版本。
在步骤564中,客户端应用以获取属性(get attribute)函数调用名称空间,该获取属性函数传递要检索的属性的名称(例如UUID)、到名称空间中的期望对象的路径名称、以及当该属性被认为已经存在时的时间。时间可以向下几乎到秒地提供,其提供实际上连续的能力以在文件和属性在过去存在时检索它们。
在步骤568中,名称空间试图利用所提供的路径名称找到名称空间中的对象。有可能的是,对象从未存在过,在这种情况下,期望的路径将不存在。如果是这样的话,在步骤572中,过程终止。名称空间遍历名称图形,以依次查询路径名称的每个部分(利用绑定表)并且确保所提供的时间处于其正在遍历的每个绑定的开始日期和终止日期之间。在图17的示例中,如果确定绑定482-486在所提供的时间值期间存在过,名称空间将仅仅到达对象4。如果是这样的话,过程例如移动到已经发现了对象4的步骤576。
对于对应于该特定对象和已经在获取属性函数调用中被传递的属性名称的行,对属性表进行检索。如果所提供的时间值未落在该特定属性的开始日期和终止日期的范围之内,则这表明期望的属性在过去的该时间点并不存在并且过程终止。如果属性在该时间点确实存在过,那么其相应的属性值将在步骤576中被返回给客户端应用。可选地,如果期望的属性是在特定时间存在的数字对象的UUID,那么在步骤580中,客户端应用使用该标识符来访问存储集群并检索数字对象在该时间点存在时的该数字对象。
以这种方式,客户端应用可以在存储集群中检索到在向下精确到秒的过去任何时间其存在时的该文件。因此,该实施例提供了几乎连续的备份功能而无需存储集群或客户端应用提供特定时间的系统离散备份或离散快照。
垃圾收集
当在名称绑定上调用unbind()时,不能立即忘记其所指代的对象ID,因为可能还有指向同一对象的其他名称(别名和链接)。即使没有其他的名称,也不能忘记对象ID,因为日期效能机制一般仍将允许通过不再是当前的名称绑定对对象的历史进行访问。由于名称空间不分配任何语法给对象ID,所以实际上没有与需要被释放的对象相关联的源,当然指代该对象的名称绑定除外。像CFS应用的客户端应用将想知道对象何时以怎样的任何方式都不再能通过名称空间访问,因为如果知道这点将会允许客户端例如从固定内容存储集群20中删除对象。这通常称为“垃圾收集”,并且存在若干处理它的标准算法。当然,名称空间实际上并不收集任何东西,其仅仅识别一组不再能够以任何方式被命名的对象ID。garbage()方法返回这种列表并允许客户端应用以它们希望的任何方式处理对象ID。
RAIN上的实现
名称空间的表示还存在多个优点。如在此所描述和示出的,名称空间的名称图形可以被分解成多个不同的绑定,即元组。这种表示允许通过横跨RAIN的不同节点复制和延伸绑定来将名称空间存储在RAIN内。绑定被简单地分开、复制并存储在不同的节点上。对称的、分布式算法将碎片放回在一起,以解析给定对象的路径名称。在另一个实施例中,名称空间被实现在RAIN集群上,从而提供横跨整个集群的绑定的分布。
计算机系统实施例
图24A和24B示出了适于执行本发明的实施例的计算机系统900。图24A示出了计算机系统的一种可能的物理形式。当然,计算机系统可以具有多种物理形式,这些形式包括集成电路、印刷电路板、小型手持设备(如移动电话或PDA)、个人计算机或超级计算机。计算机系统900包括监视器902、显示器904、机箱906、磁盘驱动器908、键盘910和鼠标912。磁盘914是用来传递数据到计算机系统900或从计算机系统900传递数据的计算机可读介质。
图24B是用于计算机系统900的框图的示例。大量子系统附连于系统总线920。一个或多个处理器922(也称作中央处理单元,或者CPU)耦接包括存储器924的存储设备。存储器924包括随机存取存储器(RAM)和只读存储器(ROM)。如在本领域所众所周知的,ROM用来单向地传递数据和指令给CPU,而RAM一般用来以双向的方式传递数据和指令。这两种类型的存储器都可包括下面所描述的任何适当的计算机可读介质。固定磁盘926也双向地耦接CPU;其提供附加的数据存储能力,并且也可以包括下面描述的任何计算机可读介质中。固定磁盘926可以用来存储程序、数据等,并且一般是比主存储器慢的二级存储介质(如硬盘)。应当注意到,保留在固定磁盘926内的信息在适当的情况下可以标准的方式结合作为存储器924中的虚拟存储器。可移除磁盘914可以采取下面描述的任何计算机可读介质的形式。
CPU 922也耦接于大量诸如显示器904、键盘910、鼠标912和扬声器930的输入/输出设备。通常,输入/输出设备可以是下面的任何一种:视频显示器、轨迹球、鼠标、键盘、麦克风、触敏显示器、转换器读卡器、磁带或纸带读取器、写字板、输入笔、声音或手写识别器、生物测定读取器,或者其他计算机。可选地,CPU 922可以利用网络接口940耦接到另一计算机或远程通信网络。利用这种网络接口,能够想到,在执行上述方法步骤的过程中,CPU可以接收来自网络的信息,或者可以输出信息到网络。另外,本发明的方法实施例可以仅仅在CPU 922上执行,或者可以结合共享处理的一部分的远程CPU一起在诸如因特网的网络上执行。
此外,本发明的实施例还涉及一种具有计算机可读介质的计算机存储器产品,该计算机可读介质上具有用于执行各种由计算机实现的操作的计算机代码。介质和计算机代码可以是那些为了本发明的目的而特别设计和构建的,或者它们可以是为计算机软件领域的技术人员所众所周知并可利用的类型。计算机可读介质的示例包括但不限于:诸如硬盘、软盘和磁带的磁性介质;诸如CD-ROM和全息照相装置的光学介质;诸如软式光盘的磁光介质;以及特别构造成存储和执行程序代码的硬件设备,如专用集成电路(ASIC)、可编程逻辑设备(PLD)以及ROM和RAM设备。计算机代码的示例包括机器代码,如编译器产生的代码、以及包含由使用译码器的计算机执行的较高级代码的文件。
尽管已经出于清楚理解的目的以一定的细节描述了上面的发明,但是显然,某些改变和修改可以在所附权利要求的范围内实施。因此,所描述的实施例应当认作是示例性而非限制性的,并且本发明不应限于此处给出的细节,而是应当由后面的权利要求及其等同设置的全部范围来限定。
Claims (7)
1.一种将计算机文件添加到存储集群的方法,所述方法包括:
接收识别计算机文件的第一路径名称,所述计算机文件使用客户端软件应用的第一路径名称方案;
通过所述客户端应用将所述第一路径名称解析成其构成名称部分;
利用所述名称部分在识别所述计算机文件的所述第一路径名称的名称空间应用中构建表示,所述表示形成路径,所述路径布置成从最一般的名称部分以前进的方式行进到最具体的名称部分;
将所述计算机文件传递到所述存储集群并从所述存储集群接收唯一标识符,所述唯一标识符唯一地识别存储在所述存储集群内的所述计算机文件;以及
将所述唯一标识符连同所述第一路径名称的所述表示的端存储在所述名称空间应用中,由此,所述计算机文件通过所述表示被唯一地表示在所述名称空间应用中。
2.如权利要求1所述的方法,其中,所述唯一标识符是通用唯一标识符。
3.如权利要求1所述的方法,其中,所述表示通过绑定表中的绑定来体现。
4.一种将计算机文件添加到存储集群的方法,所述方法包括:
接收识别计算机文件的第一路径名称,所述计算机文件使用第一客户端软件应用的第一路径名称方案;
调用名称空间应用的函数并传递所述第一路径名称,所述第一路径名称包括第一路径名称部分;
利用所述第一路径名称部分在识别所述计算机文件的所述第一路径名称的所述名称空间应用中构建第一表示;
将所述计算机文件存储在所述存储集群中并且接收来自所述存储集群的唯一标识符,所述唯一标识符唯一地识别存储在所述存储集群内的所述计算机文件;
接收识别所述计算机文件的第二路径名称,所述计算机文件使用第二客户端软件应用的第二路径名称方案;
调用所述名称空间应用的所述函数并传递所述第二路径名称,所述第二路径名称包括第二路径名称部分;
利用所述第二路径名称部分在识别所述计算机文件的所述第二路径名称的所述名称空间应用中构建第二表示;
将所述唯一标识符连同所述第一路径名称的所述表示和所述第二路径名称的所述表示的末端存储在所述名称空间应用中,由此,所述计算机文件通过两个所述表示被唯一地表示在所述名称空间应用中。
5.如权利要求4所述的方法,还包括:
通过所述客户端应用将所述第一路径名称解析成其所述第一路径名称部分,每个部分包括一般性方向和分隔符。
6.如权利要求5所述的方法,还包括:
使用所述部分中的每一个的所述一般性方向和分隔符来执行所述构建第一表示的步骤。
7.如权利要求4所述的方法,其中,所述唯一标识符是通用唯一标识符。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US9182208P | 2008-08-26 | 2008-08-26 | |
US61/091822 | 2008-08-26 | ||
PCT/US2009/055025 WO2010027849A1 (en) | 2008-08-26 | 2009-08-26 | Shared namespace for storage clusters |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102239476A CN102239476A (zh) | 2011-11-09 |
CN102239476B true CN102239476B (zh) | 2015-08-12 |
Family
ID=41797429
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200980143713.0A Expired - Fee Related CN102239476B (zh) | 2008-08-26 | 2009-08-26 | 用于存储集群的共享名称空间 |
Country Status (5)
Country | Link |
---|---|
US (1) | US8255430B2 (zh) |
EP (1) | EP2329379A4 (zh) |
CN (1) | CN102239476B (zh) |
CA (1) | CA2734675C (zh) |
WO (1) | WO2010027849A1 (zh) |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10055468B2 (en) * | 2007-04-30 | 2018-08-21 | Wolfram Research, Inc. | Access to data collections by a computational system |
SE533007C2 (sv) | 2008-10-24 | 2010-06-08 | Ilt Productions Ab | Distribuerad datalagring |
CN102073512B (zh) | 2009-11-23 | 2014-07-16 | 阿里巴巴集团控股有限公司 | 一种java集群应用系统代码装载及升级装置和方法 |
EP2387200B1 (en) | 2010-04-23 | 2014-02-12 | Compuverde AB | Distributed data storage |
US9824091B2 (en) * | 2010-12-03 | 2017-11-21 | Microsoft Technology Licensing, Llc | File system backup using change journal |
US8620894B2 (en) | 2010-12-21 | 2013-12-31 | Microsoft Corporation | Searching files |
US20170192684A1 (en) | 2011-05-09 | 2017-07-06 | International Business Machines Corporation | Auditing a transaction in a dispersed storage network |
US10452836B2 (en) * | 2011-05-09 | 2019-10-22 | Pure Storage, Inc. | Retrieving a hypertext markup language file from a dispersed storage network memory |
KR101572737B1 (ko) * | 2011-05-27 | 2015-11-27 | 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 | 메타데이터를 사용한 무결절성 애플리케이션 백업 및 리커버리 |
US9229818B2 (en) | 2011-07-20 | 2016-01-05 | Microsoft Technology Licensing, Llc | Adaptive retention for backup data |
US20170123931A1 (en) * | 2011-08-12 | 2017-05-04 | Nexenta Systems, Inc. | Object Storage System with a Distributed Namespace and Snapshot and Cloning Features |
US8997124B2 (en) | 2011-09-02 | 2015-03-31 | Compuverde Ab | Method for updating data in a distributed data storage system |
US9021053B2 (en) | 2011-09-02 | 2015-04-28 | Compuverde Ab | Method and device for writing data to a data storage system comprising a plurality of data storage nodes |
US8650365B2 (en) | 2011-09-02 | 2014-02-11 | Compuverde Ab | Method and device for maintaining data in a data storage system comprising a plurality of data storage nodes |
US8645978B2 (en) | 2011-09-02 | 2014-02-04 | Compuverde Ab | Method for data maintenance |
US9626378B2 (en) | 2011-09-02 | 2017-04-18 | Compuverde Ab | Method for handling requests in a storage system and a storage node for a storage system |
US8769138B2 (en) | 2011-09-02 | 2014-07-01 | Compuverde Ab | Method for data retrieval from a distributed data storage system |
US9237195B2 (en) * | 2012-04-27 | 2016-01-12 | Netapp, Inc. | Virtual storage appliance gateway |
US8799746B2 (en) | 2012-06-13 | 2014-08-05 | Caringo, Inc. | Erasure coding and replication in storage clusters |
US8762353B2 (en) | 2012-06-13 | 2014-06-24 | Caringo, Inc. | Elimination of duplicate objects in storage clusters |
US9104560B2 (en) | 2012-06-13 | 2015-08-11 | Caringo, Inc. | Two level addressing in storage clusters |
WO2014117247A1 (en) * | 2013-01-29 | 2014-08-07 | Blackberry Limited | Managing application access to certificates and keys |
US9805053B1 (en) * | 2013-02-25 | 2017-10-31 | EMC IP Holding Company LLC | Pluggable storage system for parallel query engines |
US9984083B1 (en) | 2013-02-25 | 2018-05-29 | EMC IP Holding Company LLC | Pluggable storage system for parallel query engines across non-native file systems |
US11966554B2 (en) * | 2013-09-16 | 2024-04-23 | Field Squared, Inc. | User interface defined document |
US11245639B2 (en) * | 2014-09-03 | 2022-02-08 | International Business Machines Corporation | Composition of persistent object instances linking resources across multiple, disparate systems |
US10372694B2 (en) * | 2014-10-08 | 2019-08-06 | Adobe Inc. | Structured information differentiation in naming |
CN104378427A (zh) * | 2014-11-14 | 2015-02-25 | 浪潮电子信息产业股份有限公司 | 一种保持集群关键数据一致性的方法 |
US10169124B2 (en) * | 2014-12-16 | 2019-01-01 | Samsung Electronics Co., Ltd. | Unified object interface for memory and storage system |
US10324919B2 (en) * | 2015-10-05 | 2019-06-18 | Red Hat, Inc. | Custom object paths for object storage management |
US11200207B1 (en) * | 2016-09-29 | 2021-12-14 | EMC IP Holding Company LLC | Compliance namespace separation to achieve snapshot based consistency across failover-failback while maintaining data retention regulation compliance |
CN106484428B (zh) * | 2016-10-20 | 2019-10-15 | 百度在线网络技术(北京)有限公司 | 应用构建方法和装置 |
US11102294B2 (en) * | 2017-06-09 | 2021-08-24 | Samsung Electronics Co., Ltd. | System and method for supporting energy and time efficient content distribution and delivery |
US10700711B1 (en) | 2017-11-03 | 2020-06-30 | Caringo Inc. | Multi-part upload and editing of erasure-coded objects |
US10764180B1 (en) * | 2018-02-20 | 2020-09-01 | Toshiba Memory Corporation | System and method for storing data using software defined networks |
US11726788B2 (en) | 2019-12-18 | 2023-08-15 | International Business Machines Corporation | Tuple checkout with notify in coordination namespace system |
US11327940B2 (en) | 2019-12-18 | 2022-05-10 | International Business Machines Corporation | Interlinked tuples in coordination namespace |
US11516290B2 (en) | 2019-12-18 | 2022-11-29 | International Business Machines Corporation | Sharing tuples across independent coordination namespace systems |
CN111813750A (zh) * | 2020-06-25 | 2020-10-23 | 刘坤 | 一种cad协同软件提资和绑定的方法 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1996032685A1 (en) | 1995-04-11 | 1996-10-17 | Kinetech, Inc. | Identifying data in a data processing system |
US7062490B2 (en) * | 2001-03-26 | 2006-06-13 | Microsoft Corporation | Serverless distributed file system |
US8311980B2 (en) | 2002-12-09 | 2012-11-13 | Hewlett-Packard Development Company, L.P. | Namespace consistency for a wide-area file system |
US7222119B1 (en) * | 2003-02-14 | 2007-05-22 | Google Inc. | Namespace locking scheme |
US7210125B2 (en) | 2003-07-17 | 2007-04-24 | International Business Machines Corporation | Method and system for application installation and management using an application-based naming system including aliases |
US8190741B2 (en) * | 2004-04-23 | 2012-05-29 | Neopath Networks, Inc. | Customizing a namespace in a decentralized storage environment |
US20070055703A1 (en) | 2005-09-07 | 2007-03-08 | Eyal Zimran | Namespace server using referral protocols |
US20070088702A1 (en) * | 2005-10-03 | 2007-04-19 | Fridella Stephen A | Intelligent network client for multi-protocol namespace redirection |
US7836079B2 (en) * | 2006-04-07 | 2010-11-16 | Microsoft Corporation | Virtual universal naming convention name space over local file system |
-
2009
- 2009-08-24 US US12/546,104 patent/US8255430B2/en active Active
- 2009-08-26 CN CN200980143713.0A patent/CN102239476B/zh not_active Expired - Fee Related
- 2009-08-26 WO PCT/US2009/055025 patent/WO2010027849A1/en active Application Filing
- 2009-08-26 CA CA2734675A patent/CA2734675C/en not_active Expired - Fee Related
- 2009-08-26 EP EP09812044.7A patent/EP2329379A4/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
US8255430B2 (en) | 2012-08-28 |
US20100070515A1 (en) | 2010-03-18 |
CN102239476A (zh) | 2011-11-09 |
CA2734675C (en) | 2017-03-07 |
EP2329379A1 (en) | 2011-06-08 |
EP2329379A4 (en) | 2014-12-03 |
WO2010027849A1 (en) | 2010-03-11 |
CA2734675A1 (en) | 2010-03-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102239476B (zh) | 用于存储集群的共享名称空间 | |
US11388251B2 (en) | Providing access to managed content | |
US8316066B1 (en) | Shadow directory structure in a distributed segmented file system | |
EP1701280B1 (en) | File server and method for translating user identifier | |
US20070073831A1 (en) | Providing direct access to distributed managed content | |
US20090198704A1 (en) | Method for automated network file and directory virtualization | |
WO2007149701A2 (en) | A method and system for federated resource discovery service in distributed systems | |
JP5557824B2 (ja) | 階層ファイルストレージに対する差分インデクシング方法 | |
KR20060080921A (ko) | 항목 기반 저장 플랫폼 내에서 데이터 모델링하기 위한시스템 및 방법 | |
CN113259504B (zh) | 基于DOA/handle标识解析技术的数据管理系统 | |
EP1422901A1 (en) | Client driven synchronization of file and folder content in web publishing | |
US7373393B2 (en) | File system | |
US9626378B2 (en) | Method for handling requests in a storage system and a storage node for a storage system | |
Kuz et al. | The globe infrastructure directory service | |
JP4153596B2 (ja) | コンテンツ連携システムおよびコンテンツ連携方法 | |
JP2008176387A (ja) | 文書管理サーバ及びプログラム | |
ord Neuman | The Prospero File System | |
CN116233115A (zh) | 一种海量数据文件高效持续受控共享分发方法及系统 | |
Kille | INCA directory services | |
Fresku et al. | SEMANTIC FILE SYSTEMS | |
EP1649394A2 (en) | Method and apparatus for retrieving and sorting entries from a directory |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150812 Termination date: 20190826 |