廖雪龙，谢雨来+，荣 震，秦磊华，陈俭喜，冯 丹

1.华中科技大学 计算机科学与技术学院，武汉 430074

2.华中科技大学 武汉国家光电实验室，武汉 430074

1 引言

如今的存储系统已经在可靠性、可用性和高效性方面取得了巨大的进步。然而随着数据量的增大和数据复杂度的提高，利用溯源来管理存储系统也变得越发重要[1]。溯源是描述一个数据对象的历史操作的元数据。溯源提高了数据本身所描述的价值，给出了“对象是如何创建的？它依赖了哪些其他对象？这两个对象的历史操作有何不同？”等问题的答案。在系统领域，一个对象的溯源是所有影响该对象最终状态的过程和数据[2]。

正因为溯源表露了数据的起源和产生过程，让用户对数据的理解更加透彻。相关研究机构已经认识到了数据溯源的重要性，并且在积极地探索多个领域，如科学计算、档案系统和数据库等的相关问题[3]。例如，被高能物理学家所运用的Globus toolkit收集了它执行的工作流程的溯源信息，并将其存储在一个起源库中[4]。Trio是一个跟踪数据库系统中数组溯源的系统[5]。Factor等人研究了长期保存数据对象工程中保存起源的问题[6]。源代码管理系统例如Vesta记录了编译系统的依赖库，并且当对象状态改变时会做出相应的行动[7]。

所有这些解决方法都处理了在某特定应用领域中出现的溯源问题。然而，它们限定在了特定的领域或者需要应用程序的修改。很多系统会将数据从它所描述的溯源中独立出来进行维护。从数据中分离溯源能够在复制和重命名中导致溯源和数据之间的不一致性。因此，溯源已逐渐由存储系统来进行维护，典型的比如PASS[8（]provenance-aware storage system）。毕竟，溯源信息仅仅是元数据，而存储系统一直都是管理元数据的。

另一方面，对象存储已作为分布式体系结构的典型解决方案，具有可用性、可靠性、可扩展性和吞吐率高等特性，代表性的对象存储系统有Lustre[9]、Panasas[10]、Ceph[11]。

利用对象存储系统来处理溯源有如下好处：

（1）不同粒度不同大小的溯源信息可以封装为对象信息进行存储。

（2）对象存储设备可以对存储的溯源信息进行自我管理，例如自动的溯源压缩，基于溯源进行数据重建等。

（3）分布式对象存储系统满足了对大容量溯源信息进行高速并发访问的需求。

（4）能够利用对象的读写命令来方便地存储和访问溯源信息。

本文研究如何在对象存储系统中收集和存储溯源，设计并实现了一个基于对象存储的溯源系统的基本框架。该系统充分利用对象存储体系结构，在对象存储客户端收集系统内核信息、文件格式信息及普通应用程序信息，并将收集到的溯源信息封装成对象，存储到对象存储设备端Berkeley DB数据库或日志文件中以供高效地查询。

本文组织结构如下：第2章介绍了研究背景；第3章和第4章分别阐述了基于对象的溯源存储系统的设计和实现；第5章对该系统中溯源的存储和查询性能进行了评估；第6章对全文进行了总结，并展望了未来的相关研究工作。

2 研究背景

2.1 溯源所应用的场景

（1）实验文档

溯源能够用来记录实验过程，并且能够以多种方式向科学家证明关键之处，下面列举几个实例。

①实验细节再现

科学家们往往会产生数据并发布它们。有时他们很难再现当时的数据，因为他们并没有记录下所有必要的细节。这可能会出现在忘记数据集中所使用的版本，忘记用来产生数据集的准确参数或者忘记一些用来产生数据的中间步骤。如果最终结果的起源是可用的话，它会精确地辨认出再现数据集所用细节和产生数据参数等需要的步骤。除去恢复参数，溯源也能够获取那些科学家们甚至也没意识到的依赖集。给出当前依赖于注册文件、文件系统的描述位和运行环境的复杂软件工具是特别重要的。由此看来，自动获取这些信息会让科学家们的生活更舒心。

②可用数据集验证

计算机数量的增加使得共享科学数据更加简单。然而科学家们可能需要在实验之前验证这些数据集。验证可能出现在数据集的辨别或者用来产生数据集的过程中。溯源能够在这方面帮助科学家，因为它记录了数据集的一系列变化，如数据集的版本信息、数据集的参数信息以及用于生成数据集的中间步骤来重新生成数据集。

（2）程序调试

考虑以下情况：某个用户在星期一运行了一下程序然后得到了一系列的结果，然而不被用户知道的是，系统管理员此时更新了系统库，当用户在星期二运行这个程序时，他又得到了不一样的结果。溯源能够帮助用户弄清楚为什么结果变化了。溯源包含了那些在之前程序中所使用的链接库和那些此次程序中所使用的库。链接库可以作为祖先节点在结果的溯源表中清楚地展示出来。用户能够检查这两种结果集的溯源表，并得到到底哪些链接库的改变导致了结果集的改变。除了如这个例子中展示的溯源如何被应用在由于系统链接库的改变导致的调试错误外，溯源还能够被类似地应用到检测由于输入序列、操作过程改变还有参数改变等导致的问题。

（3）安全

溯源对于数据安全来说十分有用。由King等人开发的Backtracker工具利用溯源来查明一次系统攻击的来源[12]。一旦用户识别出一个有害的进程，这个工具会透过溯源表中的父进程来找出攻击的来源。除了辨别危害来源，用户也能利用溯源表来查明因为外部干涉导致的一系列事件，并探测至今未被查明的危害来源。而且，系统审查和溯源收集联系紧密，在两种情况中接收一个记录活动，信息流就会在文件之间传递下去。

（4）搜索

搜索是另一个溯源所应用的领域。存储系统与桌面搜索已经远远赶不上Web搜索，其中的一个原因就是网页搜索算法能够利用网页的数据结构来提炼搜索结果。而桌面搜索中并不存在同等的结构链，桌面搜索已经被迫依赖于目录分析。溯源能够帮助克服桌面搜索这方面的难题，因为它提供了一套独立于文件的链式结构。Shah等人已经证明溯源能够提升搜索结果[13]。Shah的研究首先使用了一个纯净的基于目录的搜索来筛选文档集，然后透过溯源表得出这些文档的依赖关系。例如进程P最初访问了文档A，接着访问文档B，可得出文档B简介依赖文档A，于是溯源表存在一条由B通往A的边。而且他们根据这些文档节点的出点入点的权值来进行排序，最后在搜索中得出最符合结果的文档。他们的用户从中得出这个方案对比目录搜索能够提高17%的搜索性能。此外，当前还有将溯源和网页搜索中的PageRank算法结合到一起来提高搜索的准确性的研究[14]。

2.2 溯源存储系统研究现状

目前，国内外已经研究出了多种溯源存储系统。这些系统都利用监控系统调用来对文件依赖关系的信息进行收集。例如，在应用层进行收集的SPADE（support for provenance auditing in distributed environments）[15]和 Story Book[16]，在内核态进行收集的PASS[8]和LinFS（lineage file system）[17]。有的系统只能在本地进行收集，如TREC（transparent result caching）[18]，而有的能在附网环境下（例如SPADE），甚至在云端收集溯源信息（例如PASS）。

传统的溯源系统如PASSv2（provenance-aware storage system）的系统层次结构如图1，其中的内容包括拦截层、观察层、分析层、分布层。

Fig.1 PASSv2 architecture图1 PASSv2系统结构图

（1）拦截层：拦截层拦截系统调用并且将其传递到观察层。

（2）观察层：观察层将系统调用事件翻译为溯源记录。例如，当一个进程P读取文件A时，观察层就会产生一条溯源记录“P→A”，表示P是依赖于A的。

（3）分析层：分析层处理溯源记录流，并消除其中重复的部分来确保循环依赖不会出现。

（4）分布层：分布层将进程和管道的溯源存储在cache中。当它们的溯源信息处于PASS文件对象的溯源环上时，将这些溯源记录写入磁盘上。

（5）Lasagna文件系统：Lasagna是一个将数据和溯源存储在一起的溯源文件系统。同时它将溯源信息写入了日志文件。日志的格式确保了在磁盘上出现的数据和溯源信息的一致性。然后存储在日志中的溯源信息被批量导入Berkeley DB以供高效的查询。

但是PASS也有着不小的缺陷，例如PASS的可移植性很低。因为PASS在系统内核态实现，如果要在对象文件系统上进行移植，那么就需要对文件系统的内核代码进行大量的修改来兼容PASS。这在可行性和时间成本上都是很大的问题，这也是本文不使用PASS来收集溯源的原因。

2.3 对象存储系统及管理溯源的优势

由于存储的需求越来越大，对象存储已经成为分布式存储系统的解决方案之一。对象存储系统将主机中的管理存储模块迁移到对象存储设备（objectbased storage device，OSD）中[19]。而该设备能够自主管理存储数据，并向外输出具有表现力的对象接口。对象存储系统具有可用性、可靠性、可扩展性和吞吐率高等特性，例如Lustre[9]、Panasas[10]、Ceph[11]。

基于对象存储系统来对溯源信息进行处理拥有一系列优势。首先，对象的大小不是固定的，因而可以利用对象将不同数据的溯源进行封装，并利用对象设备的智能性对存储的溯源信息进行自我管理，提高了对容量大的溯源信息进行存储和查询的性能。其次，目前的溯源存储系统还缺少分布式的部署方式，而分布式的对象存储系统能满足溯源信息的海量存储与高速访问的需求。最后，能利用存在的对象读写命令对溯源进行方便直接的访问。

3 基于对象的溯源存储系统的设计

3.1 基于对象的溯源存储系统的整体设计框架

基于对象的溯源存储系统整体设计框架如图2所示。

Fig.2 Overall design framework of provenance-aware storage system图2 基于对象的溯源存储系统整体设计框架

该系统由对象存储客户端和对象存储设备端组成。在对象存储客户端中，系统状态分析、文件格式分析、应用程序audit等3个溯源模块分别对系统状态、文件格式及普通应用程序执行等溯源信息进行收集。然后将收集得到的溯源信息传送给对象文件系统客户端。对象文件系统客户端负责将溯源信息存入缓冲区，并通过对象命令接口将溯源信息再传输给对象文件系统设备端。对象文件系统设备端负责解析对象命令，提取出溯源信息，并将溯源信息写入新创建的对象文件。对象文件系统设备端可进一步读取对象文件数据，并将这些数据逐一存储到Berkeley DB数据库中。然后溯源查询模块利用要查询的关键字对数据库进行检索，最后将查询得到的数据以报表形式进行展示。

3.2 对象文件系统

（1）对象的概念

由于使用对象来封装溯源信息，对象的定义和它所在的系统以及溯源模型有关。对于在数据库中获取溯源信息的系统来说，对象是数据元组。对于在存储系统中获取溯源信息的系统来说，对象可能是文件、文件的某部分、文件目录或者是暂存的对象，比如管道或进程等。在本文系统中，对象以文件形式表示，存储收集的溯源信息。

（2）对象文件系统客户端和设备端

本文采用基于对象的存储设备文件系统来存储溯源信息。该系统原型基于Intel的iSCSI（Internet small computer systems interface）参考实现[20]。对象文件系统客户端分为对象文件系统（object-based storage devices file system，OSDFS）、SCSI驱动上层so和SCSI驱动下层（intel_iscsi）三部分。其中，OSDFS挂载在虚拟文件系统（virtual file system switch，FS）之下，实现树状型目录的文件到一维对象的映射。

对象文件系统客户端和设备端通过在iSCSI协议上传输对象命令进行交互。对象文件系统客户端负责将溯源信息收集和传输，而对象存储设备端将溯源信息解析和存储入对象，同时导入到数据库中供高效的查询。

（3）对象命令流程

将溯源信息从对象存储客户端传输到设备端，并进行存储和访问的对象命令流程如下：

①在对象存储客户端收集溯源信息后，将其读到客户端缓冲区（buffer）中。

②调用osd_create_and_write()函数，将溯源信息传输到对象存储设备端，并写入到新创建的对象文件内。其中，对象文件的路径由无符号整数PID(parent ID)和UID(user ID)共同标识。PID和UID分别代表分区标识符和用户对象标识符。例如对设备端目录路径为/0/64的文件进行操作，则需要令PID=0x0，UID=0x64。

③新产生的对象文件ID（即PID和UID）既可以由osd_create_and_write()函数中的随机算法确定，也能由客户端中创建对象时进行指定。

④在对象存储客户端可利用对象读写命令对设备端的溯源信息进行访问。

3.3 溯源信息收集

大多数现存的溯源系统采用了两种方式来收集溯源信息：自动收集和应用程序辅助收集。在自动收集方式中，系统监听事件和追溯信息的过程对用户和应用程序都是透明的。在应用程序辅助收集方式中，应用程序明确地利用它的行动来收集溯源信息，然后将其存在溯源信息库里。本文对系统内核信息收集是自动收集方式，而文件格式分析和审计应用程序则是辅助收集方式。下面介绍这几种收集溯源信息的方式。

（1）收集系统内核溯源信息

系统状态文件中封装了系统内核相关的信息。对文件中内容进行逐条分析和筛选即可得到想要的内核信息。在对象存储系统的客户端中，读取客户端所在的系统状态文件内容。将内容筛选得到的结果产生为设备端下的对象文件，而设备端则能够对新生成的对象文件进行读取。按筛选好的格式将内核信息从对象文件存储到设备端的数据库中。同时，用户进行内核信息的查询也在设备端完成。

由于内核信息存储在设备端中，用户要查询溯源信息时不需耗费大量的I/O操作。同时整个读取溯源信息的过程是可靠安全的。

（2）收集文件格式溯源信息

溯源系统需要对文件进行解析得到文件本身的部分属性，比如文件的格式、文件的创建时间、文件的最新更改时间等，人们可以利用格式分析工具来辅助系统获取此类溯源信息。

将应用程序调用至客户端的实现模块中。利用创建管道的方式，在执行系统的同时创建一个子进程，并通过子进程来执行命令行的指令，也就是编译执行此应用程序。通过分析文件格式，能够得到文件所遵从的标准及其标准的版本，还能得到文件的类型为音频文件、图像文件、文本文件等[21]。同时，透过辅助收集，还能得到文件内容的基本格式，如每行以多少字符进行缩进等。分析文件格式的工具能有效地提高系统的实用性和可靠性。

（3）收集普通应用程序溯源信息

Linux系统下的审计（audit）功能有着能够监测文件变更的特性[22]。它使用netlink和用户空间进行通信，如果用户空间的后台程序被系统监听，这期间产生的消息都被存到日志文件中[23]。而对系统调用进行监听时，调用getname()和path_lookup()函数，当内核在对系统调用成功或失败的结果进行信息查找时，则会避免getname()函数产生的信息作为副本存储到日志文件中，因为此函数会自动产生内核态的信息。例如，当你因为不是root权限而调用chroot“(foo”)失败时，“foo”并不会出现在日志文件中。在系统调用监听退出时，如果设定“auditable”参数，就会记录下系统调用的文件名和可用的结点号。在任务退出的时候，审计的目录则被重置。

例如，执行postmark应用程序，对文件目录里的某个区域短时间内进行大量的创建/删除文件的操作。而审计功能的作用便是能够精确到每一步文件操作时，系统进行了哪些调用，文件内容有了何种变更，以及执行的应用程序的PID、PPID等信息。同时审计功能还提供查询日志文件的工具，这对本文的溯源查询工作带来极大的便捷。由于审计功能带有完善的溯源操作和极其详细的溯源信息，本文将利用此功能对应用程序的溯源信息进行收集。

对audit功能的溯源信息进行提取时，可利用其产生的当时执行的PID、PPID等信息得到执行情况。而对这些条目进行提取时，只需要利用关键字查询进行处理即可。

但审计功能也有一定的缺陷，因为每一次操作都会在日志文件中输出溯源结果，所以日志文件很容易就变得比较庞大，而某些冗余信息并不是用户需要的，在读取较长时间运行的应用程序时，日志文件过大就成为审计溯源的缺陷。而且溯源信息过于繁杂，还需要系统进一步处理成溯源条目再存入数据库中。

3.4 溯源存储和查询

以内核信息为例，溯源存储以及溯源查询实现方式如下：在对象存储客户端收集内核信息后，调用对象创建命令osd_create_and_write()在设备端创建一个文件对象，并将所获取的系统内核溯源信息传输到该文件对象中。然后分析此文件对象中的字符串，将首字符串系统名称sysname作为数据库的key，将多项溯源信息作为data存储到Berkeley DB所创建的数据库中。

Berkeley DB[24]是一个主要应用在Unix/Linux操作系统上的嵌入式数据库系统。在溯源系统中，Berkeley DB具有访问速度快，省硬盘空间等优势。它支持key/value的数据结构，数据包括key和data（或者value）两部分。因此在存储溯源信息的时候能够快捷存储多条信息，而不用经过繁杂的创建多表的过程。

4 溯源收集和存储的实现

4.1 利用系统状态文件收集内核信息

当前系统中的重要溯源信息包括操作系统的名称（sysname）、网络结点名（nodename）、内核发行级别（release）、内核发行版本（version）以及CPU架构（machine）等信息。在Linux系统中如果想要获取这些信息，则需要利用系统调用库sys/utsname.h的头文件。此头文件中封装了相关系统内核信息的结构体utsname。而要获取utsname结构体则需要调用externint uname（structutsname*_name） _THROW 函数，其中参数_name指向存放系统信息的缓冲区。然后将这些信息封装到结构体utsname中，结构体的内容如表1所示。

Table 1 Provenance information of kernel in system-status file表1 系统状态文件所包含的内核溯源信息

4.2 利用文件格式工具收集格式信息

JHOVE（JSTOR/Harvard object validation environment）[25]是一个由哈佛大学研发的能够分析文件格式的应用程序，在此系统中利用此应用程序作为溯源信息的辅助分析工具来帮助得到文件的有效信息。JHOVE提供了去识别格式，认证有效和描述数据对象的函数。格式识别是确定数据对象到底遵从哪个数据格式的过程，例如“现在有个数据对象，它的格式是什么？”格式认证是确定一个数据对象遵从的格式的级别，例如“有个格式级别为F的数据对象，对吗？”格式描述是确定一个已给格式的对象的重要详细特性，例如“有个格式为F的对象，它的重要特性有哪些？”在常规的数据存储操作中这3个函数都是十分必要的。

利用JHOVE所进行的格式有效认证是由3个等级决定的：格式良好性、有效性和一致性。当一个数据对象满足格式中的句法要求时，它是格式良好的；当一个数据对象是格式良好的并且满足附加的语义要求时，它是有效的；当一个数据对象是有效的而且从其内部提取的代表信息和外部供应的信息一致时，它是一致的。例如，一个TIFF格式的对象如果以8 Byte头部开始，再接着一个序列的图像文件目录（image file directory，IFD），每一个由一个2 Byte的entry计数和多个8 Byte的tag entry组成，那么称其为格式良好的。当这个对象满足特定的附加语义规则，例如一个RGB文件每个像素必须拥有至少3个样本值，那么它是有效的。

JHOVE是利用良好定义的公共API创建的层次结构，适应于批处理和交互式操作。这些API能够被用来创建一些兼容的插件。

JHOVE是一个Java应用程序，遵从J2SE 1.4，使用的是JDK1.4.1的API，能够在已装好J2SE应用程序的Unix系统上很好地使用。在本系统中使用jdk1.6.0_45的工具包。

利用JHOVE可分析的文件格式有：AIFF-hul音频交换文件格式、ASCII-hulASCII编码文件、BYTESTREAM任意字符流文件、GIF-hul图像变换文件、HTML-hul超文本标记语言、JPEG-hul联合图像压缩文件、PDF-hul便携式文档、TIFF-hul标签图像文件、UTF8-hul UTF8编码文件、WAVE Windows下的音频文件、XML-hul可扩展标记语言等。

利用JHOVE所分析得到的文件格式信息，可作为文件变更溯源的第一步，即此文件是利用何种格式建立的，以及能够得到其中的创建时间以及最近更新时间等。

调用JHOVE时利用创建管道的方式调用Linux命令行来编译运行。同时这个管道由pclose()函数关闭。此函数原型为FILE*popen(const char*command，const char*type)。其中type代表“r”或“w”，如果type参数不合法，errno将返回EINVAL。因此调用JHOVE的函数可编写为pFile=popen“(java-jar/usr/share/jhove/bin/JhoveView.jar”“,r”)，同时关闭管道的函数为pclose(pFile)。这样便可利用系统分析得到文件的基本格式以及创建变更日期等溯源信息。

4.3 利用audit工具收集应用程序溯源信息

在对普通的文件进行创建、删除、转移等操作时，如果信息进行了变更，那么应该如何掌握其变更过程呢？从内核版本2.6开始，在Linux内核中拥有审计功能，能够记录系统调用和文件访问，并生成日志文件，此系统调用被称作auditd。auditd能够对/etc/audit目录下的注册文件进行编辑或者使用图像接口system-config-audit。一旦注册成功，事件的通知便会生成日志文件存储在/var/log/audit/目录下的audit.log中。由于查阅日志文件是十分乏味的，有两个工具可以被用来报告结果：aureport和ausearch。

（1）对创建文件操作进行监测

在Linux系统中对文件进行创建和删除操作时，利用audit监听该文件目录便可得到添加/删除产生的溯源信息。例如，对简单的Vim操作文本的指令：

# vi test.txt

同时利用auditctl指令对该目录下的文件进行监测，便可在生成的日志文件中得到基本文件操作的溯源信息。利用aureport指令对日志文件的内容进行筛选，便可得到人们编辑文件时产生的溯源信息，得到PID、PPID、UID、EUID、SUIDFSUID、GID、EGID、SGID、FSGID等多个系统用户与组的ID。同时还可得到inode（结点号）、exi（t系统调用退出值）、success（系统调用的成功值）、arch（系统调用的处理器体系结构）等溯源信息。

（2）对postmark应用程序执行文件添加/删除进行监测

利用postmark对文件进行大量创建/删除操作，可以通过审计功能对postmark所操作的文件区进行监测操作，便可得到一系列文件创建/删除操作以及读/写操作。postmark是一个I/O密集型的应用程序。

将audit监听postmark运行过程中的数据变更输出日志文件存储在/var/log/audit/result.log中。

（3）对内核编译过程进行监测

与postmark对文件进行大量添加/删除不同，编译内核的过程可视为CPU密集型的应用程序。编译内核时会对系统中的多个部分均产生影响。因此在/usr/src目录中对内核执行编译指令时，需要利用audit对根目录进行监控来查看内核编译所产生的溯源信息。

然后在/usr/src目录中对内核编译进行操作，执行make bzImage指令生成的内核映像进行编译。编译完成后，audit功能便在日志文件中生成内核编译过程的溯源信息。

4.4 存储和查询溯源信息

以内核溯源信息为例，其存储和查询的主要流程如下：

（1）存储流程

利用对象创建和写命令将在客户端收集的内核溯源信息写入到设备端的对象文件中。然后在设备端首先创建一个名为sysDB.db的数据库，并且打开已存储系统内核信息的对象文件，将对象文件中的内容按分号为结束标识来读取每一条系统信息，并利用int DB-＞put(DB*db，DB_TXN*txnid，DBT*key，DBT*data，u_int32_t flags)函数向数据库中添加数据，当读取到换行符时停止读入数据，最后利用db_close()函数来关闭数据库。值得注意的是每一条内核信息长度都是不一样，因此在存储的时候需要通过动态分配的方式，得到每一条信息的准确长度，在磁盘上不留无用空间。

（2）查询流程

在要查询sysDB.db数据库中存储的系统内核信息时，在设备端下首先打开已存在的sysDB.db数据库，并利用int DB-＞get(DB*db，DB_TXN*txnid,DBT*key，DBT*data，u_int32_t flags)函数得到数据库中存储的所有系统溯源信息，并以列表的方式将其展示出来。值得注意的是，因此存储的时候是动态分配的，所以在读取数据库的时候也需要动态分配预存的结构体，也就是初始化。最后，再利用db_close()函数关闭数据库。

5 系统测试与评估

5.1 测试环境

本系统基于RedHat 9.0，内核版本为2.4.20-8的Linux系统，收集系统内核信息和分析文件格式均在此系统中进行。而审计功能则在Ubuntu14.04，内核版本为3.19.0-25的Linux系统中进行。以上两个系统均为macOS系统下利用VirtualBox软件所搭建的虚 拟机平台。macOS系统版本号为10.11.5，CPU型号为2.7 GHz Intel Core i5。

5.2 评估结果

5.2.1 存储查询系统内核信息

将系统内核信息等溯源信息在客户端收集后，封装成对象，然后通过CREATE_AND_WRITE对象命令写到设备端的对象文件中，然后再导入到Berkeley DB中，从客户端能够查询得到其最终信息，同时也能够在设备端通过游标查询得到结果。在设备端对数据库中的内容进行查询，得到其表项及内容，如表2所示。至此，内核信息的存储和查询模块测试成功。

Table 2 Kernel information items in database表2 内核信息数据库表项及内容

性能分析：这个模块中，利用sys/time.h下的gettimeofday()函数可测得存储查询的性能。系统收集了74 Byte的数据，数据库大小为8 KB。存储溯源信息耗时9.02 ms，而查询溯源信息耗时6.616 ms。系统内核信息存储速率较高，不过容量较大。

5.2.2 文件格式分析应用

由于JHOVE是Java应用程序，需要系统首先配置jdk1.5以上的Java开发工具，而在溯源系统客户端应用程序模块中对其进行调用。JHOVE的主要功能是读取文件并分析得到文件的格式、最近更新时间以及最初创建时间等。下面利用JHOVE对文件进行分析并得到溯源信息。

对文本文件进行格式分析，此文本文件为根目录下的readresult.txt文件，分析出格式为字符流式文件，依照的标准为2007-4-10发布的1.3版本。而文件本身的最近更改时间为2016年4月12日。收集的文件格式溯源信息如表3所示。

Table 3 Provenance information of file format表3 文件格式溯源信息

性能分析：此模块读取并分析了17.8 KB的文件，生成了360 Byte的格式分析结果。可见，文件格式分析工具产生的溯源信息较少。

5.2.3 audit应用程序溯源信息的收集

首先是audit审计规则和监控观察器的建立，对/etc/audit/auditd.conf文件进行设置，同时确定是否循环使用日志文件。同时它还能够配置审计规则记录更详细的信息，设置日志文件位置log_file=/var/log/audit/test.log。设置的重要信息如表4所示。

Table 4 Key parameters in auditing application表4 audit进程的重要参数

下面首先介绍测试评估中所使用的应用程序，然后对溯源收集的时间开销、空间开销和查询性能进行评估。

（1）应用程序

①Vim对文件进行添加/删除：该应用程序对/home/changeset目录下创建一个文本文件，并向其中添加内容，再删除。所收集的溯源信息包括文件名、文件路径、创建的方式以及所属用户组id等信息，创建的文件大小为16 Byte，而audit生成的日志文件为279 Byte。

②Postmark：一个用来执行大量文件创建和删除等事务操作的应用程序，代表了I/O密集型负载。执行Postmark可得到大量批处理的文件溯源信息。创建了764个文件，读取了243个文件，然后删除了764个文件。读取了1.36 MB的数据量，写入了4.45 MB的数据量。生成的日志文件postmark.log大小为1.404MB。

③内核编译：代表CPU密集型负载。实验中对linux-3.19.1内核源码进行编译，由于内核源码包含所有和体系结构相关的核心代码、系统数据结构等头文件以及内核进程调度、信号处理和系统调用等程序，选择对系统根目录进行审计。同时，编译内核产生日志文件，因为日志文件大小上限为6 MB，所以编译内核的溯源信息存在5个日志文件中。因此编译内核产生的溯源信息总大小为26.44 MB。

（2）溯源收集产生的时间开销

audit溯源收集对应用程序执行会产生一定的时间开销。分别在audit关闭和打开的情况下，测出应用程序执行时间，如图3所示。

Fig.3 Time consuming comparison with audit on and off图3 在audit打开与关闭时的用时比较

性能分析：在创建文件时，关闭audit的情况下，所用时间为0.084 s，而打开audit所用时间为0.096 s，因此由audit收集溯源造成的创建文件时间开销为12.5%。

Postmark以每秒500个事务的速度在文件目录/home/changeset下生成了5.81 MB的读写数据量，而audit功能生成了2.841 MB的日志文件。如图3在关闭audit功能时用时0.176 s，在打开audit功能时用时0.202 s，因此由audit收集溯源造成的Postmark运行时间开销为12.8%。

如图3在关闭audit功能时编译内核用时1309.9s，在打开audit功能时编译内核用时1 490.9 s，因此由audit收集溯源造成的内核编译时间开销为12.1%。

以上结果表明，audit在应用程序运行过程中，由于对溯源信息需要进行记录并将其写入磁盘，而每条记录的写入过程均会产生额外的时间开销。该开销是合理的，并且对于Postmark这种I/O密集型以及内核编译这种CPU密集型的应用程序开销也不会有很大的变化。

（3）溯源收集产生的空间开销

对于不同的应用程序，audit生成的溯源信息量则有所不同，如表5所示。简单的文件创建操作会生成相对文件本身大小更多的溯源信息，包含PID、UID以及相关系统调用等，而Postmark则相对增加了读取数据的量，因此溯源信息相对较少。最后内核编译过程中，audit收集得到的溯源信息对比其他应用程序而言相对较多，这是由于内核编译过程中本身所涉及的文件和进程较多，从而溯源信息量较为丰富。

Table 5 Original size and provenance size using audit表5 audit收集原始数据量及生成的溯源大小

（4）溯源查询性能

利用ausearch查询工具对3个应用程序的溯源信息进行查询，可得到查询时间均为0.001 s，这是由于audit查询过程只是对于日志文件内容进行检索的过程。而日志文件大小相差较小时，查询的时间近似相等。由此可得，audit的查询功能具有良好的检索性能。虽然audit本身的查询功能已相当强大，但在未来，将把日志文件中的溯源信息存储入数据库中进行更高效的查询。

利用audit中的aureport查询工具对3种应用程序的信息统计项中的重要数据进行报表显示，结果如表6所示。

Table 6 Data statistics of auditing applications for provenance query表6 audit溯源查询的数据统计

由表6中数据可知，与Vim创建文件和Postmark等执行1次的应用程序不同，内核编译需要多次执行编译程序，同时会操作大量的文件，产生大量进程来对各个文件进行修改，从而产生大量的相关事件信息。

5.3 测试总结

此系统能够良好地利用对象存储系统的优势收集和存储系统内核部分的溯源信息、文件格式分析以及文件变更时间等溯源信息，并在使用audit对Postmark和内核编译等应用程序的溯源收集方面具有较低的时间和空间开销，以及较好的查询性能。

6 结束语

本文利用对象存储系统在对文件存储时的高效性与可扩展性，对系统内核、文件属性（例如文件格式）以及各种应用程序的溯源信息进行了收集、存储与查询研究。

在未来的研究工作中，将在以下方面进行加强：

（1）目前能够得到的内核信息仅限于Linux系统下的封装结构，而且所获得的内容较为单一，值得继续丰富此系统内核信息结构。

（2）文件格式分析工具目前尚能做到收集文件格式信息并将其展示给需要查询的用户，但不能做到对查询结果的存储操作。由于工具本身属于Java程序，在Berkeley DB中存储的方式尚有不同，这也是值得改进的地方。

（3）审计功能由于溯源系统本身不支持，无法做到日志文件存储操作，但若将溯源系统的可扩展的内核版本更新到最近的版本，便可以对日志文件进行查询与处理操作。

另外，将对如何利用对象存储系统中的溯源信息进行数据重建、智能的管理调度等开展相关研究。

[1]Xie Yulai.High efficient management of provenance and its application research on security[D].Wuhan:Huazhong University of Science and Technology,2013.

[2]Moreau L,Freire J,Futrelle J,et al.The open provenance model:an overview[C]//LNCS 5272:Proceedings of the 2nd International Provenance and Annotation Workshop,Salt Lake City,Jun 17-18,2008.Berlin,Heidelberg:Springer,2008:323-326.

[3]Bertino E,Ghinita G,Kantarcioglu M,et al.A roadmap for privacy-enhanced secure data provenance[J].Journal of Intelligent Information Systems,2014,43(3):481-501.

[4]Tanimura Y,Seymour K,Caron E,et al.GFD-E.102 interoperability testing for the GridRPC API[S].GridRPC Working Group,2007.

[5]Carata L,Akoush S,Balakrishnan N,et al.A primer on provenance[J].Communications of theACM,2014,57(5):52-60.

[6]Bressan F,Canazza S.Digital philology in audio long-term preservation:a multidisciplinary project on experimental music[C]//Procedia Computer Science 38:Proceedings of the 10th Italian Research Conference on Digital Libraries,Padua,Jan 30-31,2014.Amsterdam:Elsevier Science Publishers B V,2014,38:48-51.

[7]Courtès L,Wurmus R.Reproducible and user-controlled software environments in HPC with guix[C]//LNCS 9523:Proceedings of the 2015 European Conference on Parallel Processing Workshops,Vienna,Aug 24-25,2015.Berlin,Heidelberg:Springer,2015:579-591.

[8]Bates A,Tian D,Butler K R B,et al.Trustworthy wholesystem provenance for the Linux kernel[C]//Proceedings of the 24th USENIX Conference on Security Symposium,Washington,Aug 12-14,2015.Berkeley:USENIX Association,2015:319-334.

[9]Qian Yingjin,Yi Ruihai,Du Yimo,et al.Dynamic I/O congestion control in scalable lustre file system[C]//Proceedings of the 29th Symposium on Mass Storage Systems and Technologies,Long Beach,May 6-10,2013.Washington:IEEE Computer Society,2013:1-5.

[10]Ren Kai,Zheng Qing,Patil S,et al.IndexFS:scaling file system metadata performance with stateless caching and bulk insertion[C]//Proceedings of the 2015 International Conference for High Performance Computing,Networking,Storage and Analysis,New Orleans,Nov 16-21,2014.Washington:IEEE Computer Society,2015:237-248.

[11]Zhang X,Gaddam S,Chronopoulos A T.Ceph distributed file system benchmarks on an openstack cloud[C]//Proceedings of the 2015 International Conference on Cloud Computing in Emerging Markets,Bangalore,Nov 25-27,2015.Washington:IEEE Computer Society,2015:113-120.

[12]King S T,Chen P M.Backtracking intrusions[J].ACM Transactions on Computer Systems,2005,23(1):51-76.

[13]Shah S,Soules C A N,Ganger G R,et al.Using provenance to aid in personal file search[C]//Proceedings of the 2007 USENIX Annual Technical Conference,Santa Clara,Jun 17-22,2007.Berkeley:USENIXAssociation,2007:171-184.

[14]Khabsa M,Giles C L.The number of scholarly documents on the public web[J].PLOS One,2014.

[15]Gehani A,Tariq D.SPADE:support for provenance auditing in distributed environments[C]//Proceedings of the 13th International Middleware Conference.New York:Springer-Verlag,2012:101-120.

[16]Xie Yulai,Feng Dan,Tan Zhipeng,et al.Unifying intrusion detection and forensic analysis via provenance awareness[J].Future Generation Computer Systems,2016,61:26-36.

[17]Wu E,Madden S,Stonebraker M.SubZero:a fine-grained lineage system for scientific databases[C]//Proceedings of the 29th International Conference on Data Engineering,Brisbane,Apr 8-12,2013.Washington:IEEE Computer Society,2013:865-876.

[18]Wang Wei,Liu Zhaohui,Jiang Yong,et al.EasyCache:a transparent in-memory data caching approach for internetware[C]//Proceedings of the 6th Asia-Pacific Symposium on Internetware,Hong Kong,China,Nov 17,2014.New York:ACM,2014:35-44.

[19]Liu Jingning,Xie Liming,Feng Dan,et al.Research on object storage device end data management strategy[J].Journal of Computer Research and Development,2010,47(10):1832-1839.

[20]Xie Yulai,Feng Dan,Li Yan,et al.Oasis:an active storage framework for object storage platform[J].Future Generation Computer Systems,2016,56:746-758.

[21]Hedstrom M.Digital preservation:a time bomb for digital libraries[J].Computers and the Humanities,1997,31(3):189-202.

[22]Cascarino R E.Audit program for auditing UNIX/Linux environments[M].2nd ed.New York:John Wiley&Sons,Inc,2015.

[23]Bates A,Tian D,Butler K R B,et al.Trustworthy wholesystem provenance for the Linux kernel[C]//Proceedings of the 24th USENIX Conference on Security Symposium,Washington,Aug 12-14,2015.Berkeley:USENIX Association,2015:319-334.

[24]Olson M A,Bostic K,Seltzer M I.Berkeley DB[C]//Proceedings of the 1999 Annual Conference on USENIX Annual Technical Conference,Monterey,Jun 6-11,1999.Berkeley:USENIXAssociation,1999:183-191.

[25]Pellegrino J,Maggiora M,Allasia W.A multi-agent approach for autonomous digital preservation[C]//Proceedings of the 2015 International Conference on Multimedia&Expo Workshops,Turin,Jun 29-Jul 3,2015.Washington:IEEE Computer Society,2015:1-6.

附中文参考文献：

[1]谢雨来.溯源的高效存储管理及在安全方面的应用研究[D].武汉:华中科技大学,2013.

[19]刘景宁,谢黎明,冯丹,等.对象存储设备端数据管理策略研究[J].计算机研究与发展,2010,47(10):1832-1839.