對象存儲下的溯源收集與存儲研究*

廖雪龍，謝雨來+，榮 震，秦磊華，陳儉喜，馮 丹

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.