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

1.華中科技大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，武漢 430074

2.華中科技大學(xué) 武漢國家光電實(shí)驗(yàn)室，武漢 430074

1 引言

如今的存儲(chǔ)系統(tǒng)已經(jīng)在可靠性、可用性和高效性方面取得了巨大的進(jìn)步。然而隨著數(shù)據(jù)量的增大和數(shù)據(jù)復(fù)雜度的提高，利用溯源來管理存儲(chǔ)系統(tǒng)也變得越發(fā)重要[1]。溯源是描述一個(gè)數(shù)據(jù)對(duì)象的歷史操作的元數(shù)據(jù)。溯源提高了數(shù)據(jù)本身所描述的價(jià)值，給出了“對(duì)象是如何創(chuàng)建的？它依賴了哪些其他對(duì)象？這兩個(gè)對(duì)象的歷史操作有何不同？”等問題的答案。在系統(tǒng)領(lǐng)域，一個(gè)對(duì)象的溯源是所有影響該對(duì)象最終狀態(tài)的過程和數(shù)據(jù)[2]。

正因?yàn)樗菰幢砺读藬?shù)據(jù)的起源和產(chǎn)生過程，讓用戶對(duì)數(shù)據(jù)的理解更加透徹。相關(guān)研究機(jī)構(gòu)已經(jīng)認(rèn)識(shí)到了數(shù)據(jù)溯源的重要性，并且在積極地探索多個(gè)領(lǐng)域，如科學(xué)計(jì)算、檔案系統(tǒng)和數(shù)據(jù)庫等的相關(guān)問題[3]。例如，被高能物理學(xué)家所運(yùn)用的Globus toolkit收集了它執(zhí)行的工作流程的溯源信息，并將其存儲(chǔ)在一個(gè)起源庫中[4]。Trio是一個(gè)跟蹤數(shù)據(jù)庫系統(tǒng)中數(shù)組溯源的系統(tǒng)[5]。Factor等人研究了長期保存數(shù)據(jù)對(duì)象工程中保存起源的問題[6]。源代碼管理系統(tǒng)例如Vesta記錄了編譯系統(tǒng)的依賴庫，并且當(dāng)對(duì)象狀態(tài)改變時(shí)會(huì)做出相應(yīng)的行動(dòng)[7]。

所有這些解決方法都處理了在某特定應(yīng)用領(lǐng)域中出現(xiàn)的溯源問題。然而，它們限定在了特定的領(lǐng)域或者需要應(yīng)用程序的修改。很多系統(tǒng)會(huì)將數(shù)據(jù)從它所描述的溯源中獨(dú)立出來進(jìn)行維護(hù)。從數(shù)據(jù)中分離溯源能夠在復(fù)制和重命名中導(dǎo)致溯源和數(shù)據(jù)之間的不一致性。因此，溯源已逐漸由存儲(chǔ)系統(tǒng)來進(jìn)行維護(hù)，典型的比如PASS[8（]provenance-aware storage system）。畢竟，溯源信息僅僅是元數(shù)據(jù)，而存儲(chǔ)系統(tǒng)一直都是管理元數(shù)據(jù)的。

另一方面，對(duì)象存儲(chǔ)已作為分布式體系結(jié)構(gòu)的典型解決方案，具有可用性、可靠性、可擴(kuò)展性和吞吐率高等特性，代表性的對(duì)象存儲(chǔ)系統(tǒng)有Lustre[9]、Panasas[10]、Ceph[11]。

利用對(duì)象存儲(chǔ)系統(tǒng)來處理溯源有如下好處：

（1）不同粒度不同大小的溯源信息可以封裝為對(duì)象信息進(jìn)行存儲(chǔ)。

（2）對(duì)象存儲(chǔ)設(shè)備可以對(duì)存儲(chǔ)的溯源信息進(jìn)行自我管理，例如自動(dòng)的溯源壓縮，基于溯源進(jìn)行數(shù)據(jù)重建等。

（3）分布式對(duì)象存儲(chǔ)系統(tǒng)滿足了對(duì)大容量溯源信息進(jìn)行高速并發(fā)訪問的需求。

（4）能夠利用對(duì)象的讀寫命令來方便地存儲(chǔ)和訪問溯源信息。

本文研究如何在對(duì)象存儲(chǔ)系統(tǒng)中收集和存儲(chǔ)溯源，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)基于對(duì)象存儲(chǔ)的溯源系統(tǒng)的基本框架。該系統(tǒng)充分利用對(duì)象存儲(chǔ)體系結(jié)構(gòu)，在對(duì)象存儲(chǔ)客戶端收集系統(tǒng)內(nèi)核信息、文件格式信息及普通應(yīng)用程序信息，并將收集到的溯源信息封裝成對(duì)象，存儲(chǔ)到對(duì)象存儲(chǔ)設(shè)備端Berkeley DB數(shù)據(jù)庫或日志文件中以供高效地查詢。

本文組織結(jié)構(gòu)如下：第2章介紹了研究背景；第3章和第4章分別闡述了基于對(duì)象的溯源存儲(chǔ)系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)；第5章對(duì)該系統(tǒng)中溯源的存儲(chǔ)和查詢性能進(jìn)行了評(píng)估；第6章對(duì)全文進(jìn)行了總結(jié)，并展望了未來的相關(guān)研究工作。

2 研究背景

2.1 溯源所應(yīng)用的場景

（1）實(shí)驗(yàn)文檔

溯源能夠用來記錄實(shí)驗(yàn)過程，并且能夠以多種方式向科學(xué)家證明關(guān)鍵之處，下面列舉幾個(gè)實(shí)例。

①實(shí)驗(yàn)細(xì)節(jié)再現(xiàn)

科學(xué)家們往往會(huì)產(chǎn)生數(shù)據(jù)并發(fā)布它們。有時(shí)他們很難再現(xiàn)當(dāng)時(shí)的數(shù)據(jù)，因?yàn)樗麄儾]有記錄下所有必要的細(xì)節(jié)。這可能會(huì)出現(xiàn)在忘記數(shù)據(jù)集中所使用的版本，忘記用來產(chǎn)生數(shù)據(jù)集的準(zhǔn)確參數(shù)或者忘記一些用來產(chǎn)生數(shù)據(jù)的中間步驟。如果最終結(jié)果的起源是可用的話，它會(huì)精確地辨認(rèn)出再現(xiàn)數(shù)據(jù)集所用細(xì)節(jié)和產(chǎn)生數(shù)據(jù)參數(shù)等需要的步驟。除去恢復(fù)參數(shù)，溯源也能夠獲取那些科學(xué)家們甚至也沒意識(shí)到的依賴集。給出當(dāng)前依賴于注冊(cè)文件、文件系統(tǒng)的描述位和運(yùn)行環(huán)境的復(fù)雜軟件工具是特別重要的。由此看來，自動(dòng)獲取這些信息會(huì)讓科學(xué)家們的生活更舒心。

②可用數(shù)據(jù)集驗(yàn)證

計(jì)算機(jī)數(shù)量的增加使得共享科學(xué)數(shù)據(jù)更加簡單。然而科學(xué)家們可能需要在實(shí)驗(yàn)之前驗(yàn)證這些數(shù)據(jù)集。驗(yàn)證可能出現(xiàn)在數(shù)據(jù)集的辨別或者用來產(chǎn)生數(shù)據(jù)集的過程中。溯源能夠在這方面幫助科學(xué)家，因?yàn)樗涗浟藬?shù)據(jù)集的一系列變化，如數(shù)據(jù)集的版本信息、數(shù)據(jù)集的參數(shù)信息以及用于生成數(shù)據(jù)集的中間步驟來重新生成數(shù)據(jù)集。

（2）程序調(diào)試

考慮以下情況：某個(gè)用戶在星期一運(yùn)行了一下程序然后得到了一系列的結(jié)果，然而不被用戶知道的是，系統(tǒng)管理員此時(shí)更新了系統(tǒng)庫，當(dāng)用戶在星期二運(yùn)行這個(gè)程序時(shí)，他又得到了不一樣的結(jié)果。溯源能夠幫助用戶弄清楚為什么結(jié)果變化了。溯源包含了那些在之前程序中所使用的鏈接庫和那些此次程序中所使用的庫。鏈接庫可以作為祖先節(jié)點(diǎn)在結(jié)果的溯源表中清楚地展示出來。用戶能夠檢查這兩種結(jié)果集的溯源表，并得到到底哪些鏈接庫的改變導(dǎo)致了結(jié)果集的改變。除了如這個(gè)例子中展示的溯源如何被應(yīng)用在由于系統(tǒng)鏈接庫的改變導(dǎo)致的調(diào)試錯(cuò)誤外，溯源還能夠被類似地應(yīng)用到檢測由于輸入序列、操作過程改變還有參數(shù)改變等導(dǎo)致的問題。

（3）安全

溯源對(duì)于數(shù)據(jù)安全來說十分有用。由King等人開發(fā)的Backtracker工具利用溯源來查明一次系統(tǒng)攻擊的來源[12]。一旦用戶識(shí)別出一個(gè)有害的進(jìn)程，這個(gè)工具會(huì)透過溯源表中的父進(jìn)程來找出攻擊的來源。除了辨別危害來源，用戶也能利用溯源表來查明因?yàn)橥獠扛缮鎸?dǎo)致的一系列事件，并探測至今未被查明的危害來源。而且，系統(tǒng)審查和溯源收集聯(lián)系緊密，在兩種情況中接收一個(gè)記錄活動(dòng)，信息流就會(huì)在文件之間傳遞下去。

（4）搜索

搜索是另一個(gè)溯源所應(yīng)用的領(lǐng)域。存儲(chǔ)系統(tǒng)與桌面搜索已經(jīng)遠(yuǎn)遠(yuǎn)趕不上Web搜索，其中的一個(gè)原因就是網(wǎng)頁搜索算法能夠利用網(wǎng)頁的數(shù)據(jù)結(jié)構(gòu)來提煉搜索結(jié)果。而桌面搜索中并不存在同等的結(jié)構(gòu)鏈，桌面搜索已經(jīng)被迫依賴于目錄分析。溯源能夠幫助克服桌面搜索這方面的難題，因?yàn)樗峁┝艘惶转?dú)立于文件的鏈?zhǔn)浇Y(jié)構(gòu)。Shah等人已經(jīng)證明溯源能夠提升搜索結(jié)果[13]。Shah的研究首先使用了一個(gè)純凈的基于目錄的搜索來篩選文檔集，然后透過溯源表得出這些文檔的依賴關(guān)系。例如進(jìn)程P最初訪問了文檔A，接著訪問文檔B，可得出文檔B簡介依賴文檔A，于是溯源表存在一條由B通往A的邊。而且他們根據(jù)這些文檔節(jié)點(diǎn)的出點(diǎn)入點(diǎn)的權(quán)值來進(jìn)行排序，最后在搜索中得出最符合結(jié)果的文檔。他們的用戶從中得出這個(gè)方案對(duì)比目錄搜索能夠提高17%的搜索性能。此外，當(dāng)前還有將溯源和網(wǎng)頁搜索中的PageRank算法結(jié)合到一起來提高搜索的準(zhǔn)確性的研究[14]。

2.2 溯源存儲(chǔ)系統(tǒng)研究現(xiàn)狀

目前，國內(nèi)外已經(jīng)研究出了多種溯源存儲(chǔ)系統(tǒng)。這些系統(tǒng)都利用監(jiān)控系統(tǒng)調(diào)用來對(duì)文件依賴關(guān)系的信息進(jìn)行收集。例如，在應(yīng)用層進(jìn)行收集的SPADE（support for provenance auditing in distributed environments）[15]和 Story Book[16]，在內(nèi)核態(tài)進(jìn)行收集的PASS[8]和LinFS（lineage file system）[17]。有的系統(tǒng)只能在本地進(jìn)行收集，如TREC（transparent result caching）[18]，而有的能在附網(wǎng)環(huán)境下（例如SPADE），甚至在云端收集溯源信息（例如PASS）。

傳統(tǒng)的溯源系統(tǒng)如PASSv2（provenance-aware storage system）的系統(tǒng)層次結(jié)構(gòu)如圖1，其中的內(nèi)容包括攔截層、觀察層、分析層、分布層。

Fig.1 PASSv2 architecture圖1 PASSv2系統(tǒng)結(jié)構(gòu)圖

（1）攔截層：攔截層攔截系統(tǒng)調(diào)用并且將其傳遞到觀察層。

（2）觀察層：觀察層將系統(tǒng)調(diào)用事件翻譯為溯源記錄。例如，當(dāng)一個(gè)進(jìn)程P讀取文件A時(shí)，觀察層就會(huì)產(chǎn)生一條溯源記錄“P→A”，表示P是依賴于A的。

（3）分析層：分析層處理溯源記錄流，并消除其中重復(fù)的部分來確保循環(huán)依賴不會(huì)出現(xiàn)。

（4）分布層：分布層將進(jìn)程和管道的溯源存儲(chǔ)在cache中。當(dāng)它們的溯源信息處于PASS文件對(duì)象的溯源環(huán)上時(shí)，將這些溯源記錄寫入磁盤上。

（5）Lasagna文件系統(tǒng)：Lasagna是一個(gè)將數(shù)據(jù)和溯源存儲(chǔ)在一起的溯源文件系統(tǒng)。同時(shí)它將溯源信息寫入了日志文件。日志的格式確保了在磁盤上出現(xiàn)的數(shù)據(jù)和溯源信息的一致性。然后存儲(chǔ)在日志中的溯源信息被批量導(dǎo)入Berkeley DB以供高效的查詢。

但是PASS也有著不小的缺陷，例如PASS的可移植性很低。因?yàn)镻ASS在系統(tǒng)內(nèi)核態(tài)實(shí)現(xiàn)，如果要在對(duì)象文件系統(tǒng)上進(jìn)行移植，那么就需要對(duì)文件系統(tǒng)的內(nèi)核代碼進(jìn)行大量的修改來兼容PASS。這在可行性和時(shí)間成本上都是很大的問題，這也是本文不使用PASS來收集溯源的原因。

2.3 對(duì)象存儲(chǔ)系統(tǒng)及管理溯源的優(yōu)勢

由于存儲(chǔ)的需求越來越大，對(duì)象存儲(chǔ)已經(jīng)成為分布式存儲(chǔ)系統(tǒng)的解決方案之一。對(duì)象存儲(chǔ)系統(tǒng)將主機(jī)中的管理存儲(chǔ)模塊遷移到對(duì)象存儲(chǔ)設(shè)備（objectbased storage device，OSD）中[19]。而該設(shè)備能夠自主管理存儲(chǔ)數(shù)據(jù)，并向外輸出具有表現(xiàn)力的對(duì)象接口。對(duì)象存儲(chǔ)系統(tǒng)具有可用性、可靠性、可擴(kuò)展性和吞吐率高等特性，例如Lustre[9]、Panasas[10]、Ceph[11]。

基于對(duì)象存儲(chǔ)系統(tǒng)來對(duì)溯源信息進(jìn)行處理擁有一系列優(yōu)勢。首先，對(duì)象的大小不是固定的，因而可以利用對(duì)象將不同數(shù)據(jù)的溯源進(jìn)行封裝，并利用對(duì)象設(shè)備的智能性對(duì)存儲(chǔ)的溯源信息進(jìn)行自我管理，提高了對(duì)容量大的溯源信息進(jìn)行存儲(chǔ)和查詢的性能。其次，目前的溯源存儲(chǔ)系統(tǒng)還缺少分布式的部署方式，而分布式的對(duì)象存儲(chǔ)系統(tǒng)能滿足溯源信息的海量存儲(chǔ)與高速訪問的需求。最后，能利用存在的對(duì)象讀寫命令對(duì)溯源進(jìn)行方便直接的訪問。

3 基于對(duì)象的溯源存儲(chǔ)系統(tǒng)的設(shè)計(jì)

3.1 基于對(duì)象的溯源存儲(chǔ)系統(tǒng)的整體設(shè)計(jì)框架

基于對(duì)象的溯源存儲(chǔ)系統(tǒng)整體設(shè)計(jì)框架如圖2所示。

Fig.2 Overall design framework of provenance-aware storage system圖2 基于對(duì)象的溯源存儲(chǔ)系統(tǒng)整體設(shè)計(jì)框架

該系統(tǒng)由對(duì)象存儲(chǔ)客戶端和對(duì)象存儲(chǔ)設(shè)備端組成。在對(duì)象存儲(chǔ)客戶端中，系統(tǒng)狀態(tài)分析、文件格式分析、應(yīng)用程序audit等3個(gè)溯源模塊分別對(duì)系統(tǒng)狀態(tài)、文件格式及普通應(yīng)用程序執(zhí)行等溯源信息進(jìn)行收集。然后將收集得到的溯源信息傳送給對(duì)象文件系統(tǒng)客戶端。對(duì)象文件系統(tǒng)客戶端負(fù)責(zé)將溯源信息存入緩沖區(qū)，并通過對(duì)象命令接口將溯源信息再傳輸給對(duì)象文件系統(tǒng)設(shè)備端。對(duì)象文件系統(tǒng)設(shè)備端負(fù)責(zé)解析對(duì)象命令，提取出溯源信息，并將溯源信息寫入新創(chuàng)建的對(duì)象文件。對(duì)象文件系統(tǒng)設(shè)備端可進(jìn)一步讀取對(duì)象文件數(shù)據(jù)，并將這些數(shù)據(jù)逐一存儲(chǔ)到Berkeley DB數(shù)據(jù)庫中。然后溯源查詢模塊利用要查詢的關(guān)鍵字對(duì)數(shù)據(jù)庫進(jìn)行檢索，最后將查詢得到的數(shù)據(jù)以報(bào)表形式進(jìn)行展示。

3.2 對(duì)象文件系統(tǒng)

（1）對(duì)象的概念

由于使用對(duì)象來封裝溯源信息，對(duì)象的定義和它所在的系統(tǒng)以及溯源模型有關(guān)。對(duì)于在數(shù)據(jù)庫中獲取溯源信息的系統(tǒng)來說，對(duì)象是數(shù)據(jù)元組。對(duì)于在存儲(chǔ)系統(tǒng)中獲取溯源信息的系統(tǒng)來說，對(duì)象可能是文件、文件的某部分、文件目錄或者是暫存的對(duì)象，比如管道或進(jìn)程等。在本文系統(tǒng)中，對(duì)象以文件形式表示，存儲(chǔ)收集的溯源信息。

（2）對(duì)象文件系統(tǒng)客戶端和設(shè)備端

本文采用基于對(duì)象的存儲(chǔ)設(shè)備文件系統(tǒng)來存儲(chǔ)溯源信息。該系統(tǒng)原型基于Intel的iSCSI（Internet small computer systems interface）參考實(shí)現(xiàn)[20]。對(duì)象文件系統(tǒng)客戶端分為對(duì)象文件系統(tǒng)（object-based storage devices file system，OSDFS）、SCSI驅(qū)動(dòng)上層so和SCSI驅(qū)動(dòng)下層（intel_iscsi）三部分。其中，OSDFS掛載在虛擬文件系統(tǒng)（virtual file system switch，F(xiàn)S）之下，實(shí)現(xiàn)樹狀型目錄的文件到一維對(duì)象的映射。

對(duì)象文件系統(tǒng)客戶端和設(shè)備端通過在iSCSI協(xié)議上傳輸對(duì)象命令進(jìn)行交互。對(duì)象文件系統(tǒng)客戶端負(fù)責(zé)將溯源信息收集和傳輸，而對(duì)象存儲(chǔ)設(shè)備端將溯源信息解析和存儲(chǔ)入對(duì)象，同時(shí)導(dǎo)入到數(shù)據(jù)庫中供高效的查詢。

（3）對(duì)象命令流程

將溯源信息從對(duì)象存儲(chǔ)客戶端傳輸?shù)皆O(shè)備端，并進(jìn)行存儲(chǔ)和訪問的對(duì)象命令流程如下：

①在對(duì)象存儲(chǔ)客戶端收集溯源信息后，將其讀到客戶端緩沖區(qū)（buffer）中。

②調(diào)用osd_create_and_write()函數(shù)，將溯源信息傳輸?shù)綄?duì)象存儲(chǔ)設(shè)備端，并寫入到新創(chuàng)建的對(duì)象文件內(nèi)。其中，對(duì)象文件的路徑由無符號(hào)整數(shù)PID(parent ID)和UID(user ID)共同標(biāo)識(shí)。PID和UID分別代表分區(qū)標(biāo)識(shí)符和用戶對(duì)象標(biāo)識(shí)符。例如對(duì)設(shè)備端目錄路徑為/0/64的文件進(jìn)行操作，則需要令PID=0x0，UID=0x64。

③新產(chǎn)生的對(duì)象文件ID（即PID和UID）既可以由osd_create_and_write()函數(shù)中的隨機(jī)算法確定，也能由客戶端中創(chuàng)建對(duì)象時(shí)進(jìn)行指定。

④在對(duì)象存儲(chǔ)客戶端可利用對(duì)象讀寫命令對(duì)設(shè)備端的溯源信息進(jìn)行訪問。

3.3 溯源信息收集

大多數(shù)現(xiàn)存的溯源系統(tǒng)采用了兩種方式來收集溯源信息：自動(dòng)收集和應(yīng)用程序輔助收集。在自動(dòng)收集方式中，系統(tǒng)監(jiān)聽事件和追溯信息的過程對(duì)用戶和應(yīng)用程序都是透明的。在應(yīng)用程序輔助收集方式中，應(yīng)用程序明確地利用它的行動(dòng)來收集溯源信息，然后將其存在溯源信息庫里。本文對(duì)系統(tǒng)內(nèi)核信息收集是自動(dòng)收集方式，而文件格式分析和審計(jì)應(yīng)用程序則是輔助收集方式。下面介紹這幾種收集溯源信息的方式。

（1）收集系統(tǒng)內(nèi)核溯源信息

系統(tǒng)狀態(tài)文件中封裝了系統(tǒng)內(nèi)核相關(guān)的信息。對(duì)文件中內(nèi)容進(jìn)行逐條分析和篩選即可得到想要的內(nèi)核信息。在對(duì)象存儲(chǔ)系統(tǒng)的客戶端中，讀取客戶端所在的系統(tǒng)狀態(tài)文件內(nèi)容。將內(nèi)容篩選得到的結(jié)果產(chǎn)生為設(shè)備端下的對(duì)象文件，而設(shè)備端則能夠?qū)π律傻膶?duì)象文件進(jìn)行讀取。按篩選好的格式將內(nèi)核信息從對(duì)象文件存儲(chǔ)到設(shè)備端的數(shù)據(jù)庫中。同時(shí)，用戶進(jìn)行內(nèi)核信息的查詢也在設(shè)備端完成。

由于內(nèi)核信息存儲(chǔ)在設(shè)備端中，用戶要查詢溯源信息時(shí)不需耗費(fèi)大量的I/O操作。同時(shí)整個(gè)讀取溯源信息的過程是可靠安全的。

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

溯源系統(tǒng)需要對(duì)文件進(jìn)行解析得到文件本身的部分屬性，比如文件的格式、文件的創(chuàng)建時(shí)間、文件的最新更改時(shí)間等，人們可以利用格式分析工具來輔助系統(tǒng)獲取此類溯源信息。

將應(yīng)用程序調(diào)用至客戶端的實(shí)現(xiàn)模塊中。利用創(chuàng)建管道的方式，在執(zhí)行系統(tǒng)的同時(shí)創(chuàng)建一個(gè)子進(jìn)程，并通過子進(jìn)程來執(zhí)行命令行的指令，也就是編譯執(zhí)行此應(yīng)用程序。通過分析文件格式，能夠得到文件所遵從的標(biāo)準(zhǔn)及其標(biāo)準(zhǔn)的版本，還能得到文件的類型為音頻文件、圖像文件、文本文件等[21]。同時(shí)，透過輔助收集，還能得到文件內(nèi)容的基本格式，如每行以多少字符進(jìn)行縮進(jìn)等。分析文件格式的工具能有效地提高系統(tǒng)的實(shí)用性和可靠性。

（3）收集普通應(yīng)用程序溯源信息

Linux系統(tǒng)下的審計(jì)（audit）功能有著能夠監(jiān)測文件變更的特性[22]。它使用netlink和用戶空間進(jìn)行通信，如果用戶空間的后臺(tái)程序被系統(tǒng)監(jiān)聽，這期間產(chǎn)生的消息都被存到日志文件中[23]。而對(duì)系統(tǒng)調(diào)用進(jìn)行監(jiān)聽時(shí)，調(diào)用getname()和path_lookup()函數(shù)，當(dāng)內(nèi)核在對(duì)系統(tǒng)調(diào)用成功或失敗的結(jié)果進(jìn)行信息查找時(shí)，則會(huì)避免getname()函數(shù)產(chǎn)生的信息作為副本存儲(chǔ)到日志文件中，因?yàn)榇撕瘮?shù)會(huì)自動(dòng)產(chǎn)生內(nèi)核態(tài)的信息。例如，當(dāng)你因?yàn)椴皇莚oot權(quán)限而調(diào)用chroot“(foo”)失敗時(shí)，“foo”并不會(huì)出現(xiàn)在日志文件中。在系統(tǒng)調(diào)用監(jiān)聽退出時(shí)，如果設(shè)定“auditable”參數(shù)，就會(huì)記錄下系統(tǒng)調(diào)用的文件名和可用的結(jié)點(diǎn)號(hào)。在任務(wù)退出的時(shí)候，審計(jì)的目錄則被重置。

例如，執(zhí)行postmark應(yīng)用程序，對(duì)文件目錄里的某個(gè)區(qū)域短時(shí)間內(nèi)進(jìn)行大量的創(chuàng)建/刪除文件的操作。而審計(jì)功能的作用便是能夠精確到每一步文件操作時(shí)，系統(tǒng)進(jìn)行了哪些調(diào)用，文件內(nèi)容有了何種變更，以及執(zhí)行的應(yīng)用程序的PID、PPID等信息。同時(shí)審計(jì)功能還提供查詢?nèi)罩疚募墓ぞ?，這對(duì)本文的溯源查詢工作帶來極大的便捷。由于審計(jì)功能帶有完善的溯源操作和極其詳細(xì)的溯源信息，本文將利用此功能對(duì)應(yīng)用程序的溯源信息進(jìn)行收集。

對(duì)audit功能的溯源信息進(jìn)行提取時(shí)，可利用其產(chǎn)生的當(dāng)時(shí)執(zhí)行的PID、PPID等信息得到執(zhí)行情況。而對(duì)這些條目進(jìn)行提取時(shí)，只需要利用關(guān)鍵字查詢進(jìn)行處理即可。

但審計(jì)功能也有一定的缺陷，因?yàn)槊恳淮尾僮鞫紩?huì)在日志文件中輸出溯源結(jié)果，所以日志文件很容易就變得比較龐大，而某些冗余信息并不是用戶需要的，在讀取較長時(shí)間運(yùn)行的應(yīng)用程序時(shí)，日志文件過大就成為審計(jì)溯源的缺陷。而且溯源信息過于繁雜，還需要系統(tǒng)進(jìn)一步處理成溯源條目再存入數(shù)據(jù)庫中。

3.4 溯源存儲(chǔ)和查詢

以內(nèi)核信息為例，溯源存儲(chǔ)以及溯源查詢實(shí)現(xiàn)方式如下：在對(duì)象存儲(chǔ)客戶端收集內(nèi)核信息后，調(diào)用對(duì)象創(chuàng)建命令osd_create_and_write()在設(shè)備端創(chuàng)建一個(gè)文件對(duì)象，并將所獲取的系統(tǒng)內(nèi)核溯源信息傳輸?shù)皆撐募?duì)象中。然后分析此文件對(duì)象中的字符串，將首字符串系統(tǒng)名稱sysname作為數(shù)據(jù)庫的key，將多項(xiàng)溯源信息作為data存儲(chǔ)到Berkeley DB所創(chuàng)建的數(shù)據(jù)庫中。

Berkeley DB[24]是一個(gè)主要應(yīng)用在Unix/Linux操作系統(tǒng)上的嵌入式數(shù)據(jù)庫系統(tǒng)。在溯源系統(tǒng)中，Berkeley DB具有訪問速度快，省硬盤空間等優(yōu)勢。它支持key/value的數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)包括key和data（或者value）兩部分。因此在存儲(chǔ)溯源信息的時(shí)候能夠快捷存儲(chǔ)多條信息，而不用經(jīng)過繁雜的創(chuàng)建多表的過程。

4 溯源收集和存儲(chǔ)的實(shí)現(xiàn)

4.1 利用系統(tǒng)狀態(tài)文件收集內(nèi)核信息

當(dāng)前系統(tǒng)中的重要溯源信息包括操作系統(tǒng)的名稱（sysname）、網(wǎng)絡(luò)結(jié)點(diǎn)名（nodename）、內(nèi)核發(fā)行級(jí)別（release）、內(nèi)核發(fā)行版本（version）以及CPU架構(gòu)（machine）等信息。在Linux系統(tǒng)中如果想要獲取這些信息，則需要利用系統(tǒng)調(diào)用庫sys/utsname.h的頭文件。此頭文件中封裝了相關(guān)系統(tǒng)內(nèi)核信息的結(jié)構(gòu)體utsname。而要獲取utsname結(jié)構(gòu)體則需要調(diào)用externint uname（structutsname*_name） _THROW 函數(shù)，其中參數(shù)_name指向存放系統(tǒng)信息的緩沖區(qū)。然后將這些信息封裝到結(jié)構(gòu)體utsname中，結(jié)構(gòu)體的內(nèi)容如表1所示。

Table 1 Provenance information of kernel in system-status file表1 系統(tǒng)狀態(tài)文件所包含的內(nèi)核溯源信息

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

JHOVE（JSTOR/Harvard object validation environment）[25]是一個(gè)由哈佛大學(xué)研發(fā)的能夠分析文件格式的應(yīng)用程序，在此系統(tǒng)中利用此應(yīng)用程序作為溯源信息的輔助分析工具來幫助得到文件的有效信息。JHOVE提供了去識(shí)別格式，認(rèn)證有效和描述數(shù)據(jù)對(duì)象的函數(shù)。格式識(shí)別是確定數(shù)據(jù)對(duì)象到底遵從哪個(gè)數(shù)據(jù)格式的過程，例如“現(xiàn)在有個(gè)數(shù)據(jù)對(duì)象，它的格式是什么？”格式認(rèn)證是確定一個(gè)數(shù)據(jù)對(duì)象遵從的格式的級(jí)別，例如“有個(gè)格式級(jí)別為F的數(shù)據(jù)對(duì)象，對(duì)嗎？”格式描述是確定一個(gè)已給格式的對(duì)象的重要詳細(xì)特性，例如“有個(gè)格式為F的對(duì)象，它的重要特性有哪些？”在常規(guī)的數(shù)據(jù)存儲(chǔ)操作中這3個(gè)函數(shù)都是十分必要的。

利用JHOVE所進(jìn)行的格式有效認(rèn)證是由3個(gè)等級(jí)決定的：格式良好性、有效性和一致性。當(dāng)一個(gè)數(shù)據(jù)對(duì)象滿足格式中的句法要求時(shí)，它是格式良好的；當(dāng)一個(gè)數(shù)據(jù)對(duì)象是格式良好的并且滿足附加的語義要求時(shí)，它是有效的；當(dāng)一個(gè)數(shù)據(jù)對(duì)象是有效的而且從其內(nèi)部提取的代表信息和外部供應(yīng)的信息一致時(shí)，它是一致的。例如，一個(gè)TIFF格式的對(duì)象如果以8 Byte頭部開始，再接著一個(gè)序列的圖像文件目錄（image file directory，IFD），每一個(gè)由一個(gè)2 Byte的entry計(jì)數(shù)和多個(gè)8 Byte的tag entry組成，那么稱其為格式良好的。當(dāng)這個(gè)對(duì)象滿足特定的附加語義規(guī)則，例如一個(gè)RGB文件每個(gè)像素必須擁有至少3個(gè)樣本值，那么它是有效的。

JHOVE是利用良好定義的公共API創(chuàng)建的層次結(jié)構(gòu)，適應(yīng)于批處理和交互式操作。這些API能夠被用來創(chuàng)建一些兼容的插件。

JHOVE是一個(gè)Java應(yīng)用程序，遵從J2SE 1.4，使用的是JDK1.4.1的API，能夠在已裝好J2SE應(yīng)用程序的Unix系統(tǒng)上很好地使用。在本系統(tǒng)中使用jdk1.6.0_45的工具包。

利用JHOVE可分析的文件格式有：AIFF-hul音頻交換文件格式、ASCII-hulASCII編碼文件、BYTESTREAM任意字符流文件、GIF-hul圖像變換文件、HTML-hul超文本標(biāo)記語言、JPEG-hul聯(lián)合圖像壓縮文件、PDF-hul便攜式文檔、TIFF-hul標(biāo)簽圖像文件、UTF8-hul UTF8編碼文件、WAVE Windows下的音頻文件、XML-hul可擴(kuò)展標(biāo)記語言等。

利用JHOVE所分析得到的文件格式信息，可作為文件變更溯源的第一步，即此文件是利用何種格式建立的，以及能夠得到其中的創(chuàng)建時(shí)間以及最近更新時(shí)間等。

調(diào)用JHOVE時(shí)利用創(chuàng)建管道的方式調(diào)用Linux命令行來編譯運(yùn)行。同時(shí)這個(gè)管道由pclose()函數(shù)關(guān)閉。此函數(shù)原型為FILE*popen(const char*command，const char*type)。其中type代表“r”或“w”，如果type參數(shù)不合法，errno將返回EINVAL。因此調(diào)用JHOVE的函數(shù)可編寫為pFile=popen“(java-jar/usr/share/jhove/bin/JhoveView.jar”“,r”)，同時(shí)關(guān)閉管道的函數(shù)為pclose(pFile)。這樣便可利用系統(tǒng)分析得到文件的基本格式以及創(chuàng)建變更日期等溯源信息。

4.3 利用audit工具收集應(yīng)用程序溯源信息

在對(duì)普通的文件進(jìn)行創(chuàng)建、刪除、轉(zhuǎn)移等操作時(shí)，如果信息進(jìn)行了變更，那么應(yīng)該如何掌握其變更過程呢？從內(nèi)核版本2.6開始，在Linux內(nèi)核中擁有審計(jì)功能，能夠記錄系統(tǒng)調(diào)用和文件訪問，并生成日志文件，此系統(tǒng)調(diào)用被稱作auditd。auditd能夠?qū)?etc/audit目錄下的注冊(cè)文件進(jìn)行編輯或者使用圖像接口system-config-audit。一旦注冊(cè)成功，事件的通知便會(huì)生成日志文件存儲(chǔ)在/var/log/audit/目錄下的audit.log中。由于查閱日志文件是十分乏味的，有兩個(gè)工具可以被用來報(bào)告結(jié)果：aureport和ausearch。

（1）對(duì)創(chuàng)建文件操作進(jìn)行監(jiān)測

在Linux系統(tǒng)中對(duì)文件進(jìn)行創(chuàng)建和刪除操作時(shí)，利用audit監(jiān)聽該文件目錄便可得到添加/刪除產(chǎn)生的溯源信息。例如，對(duì)簡單的Vim操作文本的指令：

# vi test.txt

同時(shí)利用auditctl指令對(duì)該目錄下的文件進(jìn)行監(jiān)測，便可在生成的日志文件中得到基本文件操作的溯源信息。利用aureport指令對(duì)日志文件的內(nèi)容進(jìn)行篩選，便可得到人們編輯文件時(shí)產(chǎn)生的溯源信息，得到PID、PPID、UID、EUID、SUIDFSUID、GID、EGID、SGID、FSGID等多個(gè)系統(tǒng)用戶與組的ID。同時(shí)還可得到inode（結(jié)點(diǎn)號(hào)）、exi（t系統(tǒng)調(diào)用退出值）、success（系統(tǒng)調(diào)用的成功值）、arch（系統(tǒng)調(diào)用的處理器體系結(jié)構(gòu)）等溯源信息。

（2）對(duì)postmark應(yīng)用程序執(zhí)行文件添加/刪除進(jìn)行監(jiān)測

利用postmark對(duì)文件進(jìn)行大量創(chuàng)建/刪除操作，可以通過審計(jì)功能對(duì)postmark所操作的文件區(qū)進(jìn)行監(jiān)測操作，便可得到一系列文件創(chuàng)建/刪除操作以及讀/寫操作。postmark是一個(gè)I/O密集型的應(yīng)用程序。

將audit監(jiān)聽postmark運(yùn)行過程中的數(shù)據(jù)變更輸出日志文件存儲(chǔ)在/var/log/audit/result.log中。

（3）對(duì)內(nèi)核編譯過程進(jìn)行監(jiān)測

與postmark對(duì)文件進(jìn)行大量添加/刪除不同，編譯內(nèi)核的過程可視為CPU密集型的應(yīng)用程序。編譯內(nèi)核時(shí)會(huì)對(duì)系統(tǒng)中的多個(gè)部分均產(chǎn)生影響。因此在/usr/src目錄中對(duì)內(nèi)核執(zhí)行編譯指令時(shí)，需要利用audit對(duì)根目錄進(jìn)行監(jiān)控來查看內(nèi)核編譯所產(chǎn)生的溯源信息。

然后在/usr/src目錄中對(duì)內(nèi)核編譯進(jìn)行操作，執(zhí)行make bzImage指令生成的內(nèi)核映像進(jìn)行編譯。編譯完成后，audit功能便在日志文件中生成內(nèi)核編譯過程的溯源信息。

4.4 存儲(chǔ)和查詢溯源信息

以內(nèi)核溯源信息為例，其存儲(chǔ)和查詢的主要流程如下：

（1）存儲(chǔ)流程

利用對(duì)象創(chuàng)建和寫命令將在客戶端收集的內(nèi)核溯源信息寫入到設(shè)備端的對(duì)象文件中。然后在設(shè)備端首先創(chuàng)建一個(gè)名為sysDB.db的數(shù)據(jù)庫，并且打開已存儲(chǔ)系統(tǒng)內(nèi)核信息的對(duì)象文件，將對(duì)象文件中的內(nèi)容按分號(hào)為結(jié)束標(biāo)識(shí)來讀取每一條系統(tǒng)信息，并利用int DB-＞put(DB*db，DB_TXN*txnid，DBT*key，DBT*data，u_int32_t flags)函數(shù)向數(shù)據(jù)庫中添加數(shù)據(jù)，當(dāng)讀取到換行符時(shí)停止讀入數(shù)據(jù)，最后利用db_close()函數(shù)來關(guān)閉數(shù)據(jù)庫。值得注意的是每一條內(nèi)核信息長度都是不一樣，因此在存儲(chǔ)的時(shí)候需要通過動(dòng)態(tài)分配的方式，得到每一條信息的準(zhǔn)確長度，在磁盤上不留無用空間。

（2）查詢流程

在要查詢sysDB.db數(shù)據(jù)庫中存儲(chǔ)的系統(tǒng)內(nèi)核信息時(shí)，在設(shè)備端下首先打開已存在的sysDB.db數(shù)據(jù)庫，并利用int DB-＞get(DB*db，DB_TXN*txnid,DBT*key，DBT*data，u_int32_t flags)函數(shù)得到數(shù)據(jù)庫中存儲(chǔ)的所有系統(tǒng)溯源信息，并以列表的方式將其展示出來。值得注意的是，因此存儲(chǔ)的時(shí)候是動(dòng)態(tài)分配的，所以在讀取數(shù)據(jù)庫的時(shí)候也需要?jiǎng)討B(tài)分配預(yù)存的結(jié)構(gòu)體，也就是初始化。最后，再利用db_close()函數(shù)關(guān)閉數(shù)據(jù)庫。

5 系統(tǒng)測試與評(píng)估

5.1 測試環(huán)境

本系統(tǒng)基于RedHat 9.0，內(nèi)核版本為2.4.20-8的Linux系統(tǒng)，收集系統(tǒng)內(nèi)核信息和分析文件格式均在此系統(tǒng)中進(jìn)行。而審計(jì)功能則在Ubuntu14.04，內(nèi)核版本為3.19.0-25的Linux系統(tǒng)中進(jìn)行。以上兩個(gè)系統(tǒng)均為macOS系統(tǒng)下利用VirtualBox軟件所搭建的虛 擬機(jī)平臺(tái)。macOS系統(tǒng)版本號(hào)為10.11.5，CPU型號(hào)為2.7 GHz Intel Core i5。

5.2 評(píng)估結(jié)果

5.2.1 存儲(chǔ)查詢系統(tǒng)內(nèi)核信息

將系統(tǒng)內(nèi)核信息等溯源信息在客戶端收集后，封裝成對(duì)象，然后通過CREATE_AND_WRITE對(duì)象命令寫到設(shè)備端的對(duì)象文件中，然后再導(dǎo)入到Berkeley DB中，從客戶端能夠查詢得到其最終信息，同時(shí)也能夠在設(shè)備端通過游標(biāo)查詢得到結(jié)果。在設(shè)備端對(duì)數(shù)據(jù)庫中的內(nèi)容進(jìn)行查詢，得到其表項(xiàng)及內(nèi)容，如表2所示。至此，內(nèi)核信息的存儲(chǔ)和查詢模塊測試成功。

Table 2 Kernel information items in database表2 內(nèi)核信息數(shù)據(jù)庫表項(xiàng)及內(nèi)容

性能分析：這個(gè)模塊中，利用sys/time.h下的gettimeofday()函數(shù)可測得存儲(chǔ)查詢的性能。系統(tǒng)收集了74 Byte的數(shù)據(jù)，數(shù)據(jù)庫大小為8 KB。存儲(chǔ)溯源信息耗時(shí)9.02 ms，而查詢溯源信息耗時(shí)6.616 ms。系統(tǒng)內(nèi)核信息存儲(chǔ)速率較高，不過容量較大。

5.2.2 文件格式分析應(yīng)用

由于JHOVE是Java應(yīng)用程序，需要系統(tǒng)首先配置jdk1.5以上的Java開發(fā)工具，而在溯源系統(tǒng)客戶端應(yīng)用程序模塊中對(duì)其進(jìn)行調(diào)用。JHOVE的主要功能是讀取文件并分析得到文件的格式、最近更新時(shí)間以及最初創(chuàng)建時(shí)間等。下面利用JHOVE對(duì)文件進(jìn)行分析并得到溯源信息。

對(duì)文本文件進(jìn)行格式分析，此文本文件為根目錄下的readresult.txt文件，分析出格式為字符流式文件，依照的標(biāo)準(zhǔn)為2007-4-10發(fā)布的1.3版本。而文件本身的最近更改時(shí)間為2016年4月12日。收集的文件格式溯源信息如表3所示。

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

性能分析：此模塊讀取并分析了17.8 KB的文件，生成了360 Byte的格式分析結(jié)果?？梢?，文件格式分析工具產(chǎn)生的溯源信息較少。

5.2.3 audit應(yīng)用程序溯源信息的收集

首先是audit審計(jì)規(guī)則和監(jiān)控觀察器的建立，對(duì)/etc/audit/auditd.conf文件進(jìn)行設(shè)置，同時(shí)確定是否循環(huán)使用日志文件。同時(shí)它還能夠配置審計(jì)規(guī)則記錄更詳細(xì)的信息，設(shè)置日志文件位置log_file=/var/log/audit/test.log。設(shè)置的重要信息如表4所示。

Table 4 Key parameters in auditing application表4 audit進(jìn)程的重要參數(shù)

下面首先介紹測試評(píng)估中所使用的應(yīng)用程序，然后對(duì)溯源收集的時(shí)間開銷、空間開銷和查詢性能進(jìn)行評(píng)估。

（1）應(yīng)用程序

①Vim對(duì)文件進(jìn)行添加/刪除：該應(yīng)用程序?qū)?home/changeset目錄下創(chuàng)建一個(gè)文本文件，并向其中添加內(nèi)容，再刪除。所收集的溯源信息包括文件名、文件路徑、創(chuàng)建的方式以及所屬用戶組id等信息，創(chuàng)建的文件大小為16 Byte，而audit生成的日志文件為279 Byte。

②Postmark：一個(gè)用來執(zhí)行大量文件創(chuàng)建和刪除等事務(wù)操作的應(yīng)用程序，代表了I/O密集型負(fù)載。執(zhí)行Postmark可得到大量批處理的文件溯源信息。創(chuàng)建了764個(gè)文件，讀取了243個(gè)文件，然后刪除了764個(gè)文件。讀取了1.36 MB的數(shù)據(jù)量，寫入了4.45 MB的數(shù)據(jù)量。生成的日志文件postmark.log大小為1.404MB。

③內(nèi)核編譯：代表CPU密集型負(fù)載。實(shí)驗(yàn)中對(duì)linux-3.19.1內(nèi)核源碼進(jìn)行編譯，由于內(nèi)核源碼包含所有和體系結(jié)構(gòu)相關(guān)的核心代碼、系統(tǒng)數(shù)據(jù)結(jié)構(gòu)等頭文件以及內(nèi)核進(jìn)程調(diào)度、信號(hào)處理和系統(tǒng)調(diào)用等程序，選擇對(duì)系統(tǒng)根目錄進(jìn)行審計(jì)。同時(shí)，編譯內(nèi)核產(chǎn)生日志文件，因?yàn)槿罩疚募笮∩舷逓? MB，所以編譯內(nèi)核的溯源信息存在5個(gè)日志文件中。因此編譯內(nèi)核產(chǎn)生的溯源信息總大小為26.44 MB。

（2）溯源收集產(chǎn)生的時(shí)間開銷

audit溯源收集對(duì)應(yīng)用程序執(zhí)行會(huì)產(chǎn)生一定的時(shí)間開銷。分別在audit關(guān)閉和打開的情況下，測出應(yīng)用程序執(zhí)行時(shí)間，如圖3所示。

Fig.3 Time consuming comparison with audit on and off圖3 在audit打開與關(guān)閉時(shí)的用時(shí)比較

性能分析：在創(chuàng)建文件時(shí)，關(guān)閉audit的情況下，所用時(shí)間為0.084 s，而打開audit所用時(shí)間為0.096 s，因此由audit收集溯源造成的創(chuàng)建文件時(shí)間開銷為12.5%。

Postmark以每秒500個(gè)事務(wù)的速度在文件目錄/home/changeset下生成了5.81 MB的讀寫數(shù)據(jù)量，而audit功能生成了2.841 MB的日志文件。如圖3在關(guān)閉audit功能時(shí)用時(shí)0.176 s，在打開audit功能時(shí)用時(shí)0.202 s，因此由audit收集溯源造成的Postmark運(yùn)行時(shí)間開銷為12.8%。

如圖3在關(guān)閉audit功能時(shí)編譯內(nèi)核用時(shí)1309.9s，在打開audit功能時(shí)編譯內(nèi)核用時(shí)1 490.9 s，因此由audit收集溯源造成的內(nèi)核編譯時(shí)間開銷為12.1%。

以上結(jié)果表明，audit在應(yīng)用程序運(yùn)行過程中，由于對(duì)溯源信息需要進(jìn)行記錄并將其寫入磁盤，而每條記錄的寫入過程均會(huì)產(chǎn)生額外的時(shí)間開銷。該開銷是合理的，并且對(duì)于Postmark這種I/O密集型以及內(nèi)核編譯這種CPU密集型的應(yīng)用程序開銷也不會(huì)有很大的變化。

（3）溯源收集產(chǎn)生的空間開銷

對(duì)于不同的應(yīng)用程序，audit生成的溯源信息量則有所不同，如表5所示。簡單的文件創(chuàng)建操作會(huì)生成相對(duì)文件本身大小更多的溯源信息，包含PID、UID以及相關(guān)系統(tǒng)調(diào)用等，而Postmark則相對(duì)增加了讀取數(shù)據(jù)的量，因此溯源信息相對(duì)較少。最后內(nèi)核編譯過程中，audit收集得到的溯源信息對(duì)比其他應(yīng)用程序而言相對(duì)較多，這是由于內(nèi)核編譯過程中本身所涉及的文件和進(jìn)程較多，從而溯源信息量較為豐富。

Table 5 Original size and provenance size using audit表5 audit收集原始數(shù)據(jù)量及生成的溯源大小

（4）溯源查詢性能

利用ausearch查詢工具對(duì)3個(gè)應(yīng)用程序的溯源信息進(jìn)行查詢，可得到查詢時(shí)間均為0.001 s，這是由于audit查詢過程只是對(duì)于日志文件內(nèi)容進(jìn)行檢索的過程。而日志文件大小相差較小時(shí)，查詢的時(shí)間近似相等。由此可得，audit的查詢功能具有良好的檢索性能。雖然audit本身的查詢功能已相當(dāng)強(qiáng)大，但在未來，將把日志文件中的溯源信息存儲(chǔ)入數(shù)據(jù)庫中進(jìn)行更高效的查詢。

利用audit中的aureport查詢工具對(duì)3種應(yīng)用程序的信息統(tǒng)計(jì)項(xiàng)中的重要數(shù)據(jù)進(jìn)行報(bào)表顯示，結(jié)果如表6所示。

Table 6 Data statistics of auditing applications for provenance query表6 audit溯源查詢的數(shù)據(jù)統(tǒng)計(jì)

由表6中數(shù)據(jù)可知，與Vim創(chuàng)建文件和Postmark等執(zhí)行1次的應(yīng)用程序不同，內(nèi)核編譯需要多次執(zhí)行編譯程序，同時(shí)會(huì)操作大量的文件，產(chǎn)生大量進(jìn)程來對(duì)各個(gè)文件進(jìn)行修改，從而產(chǎn)生大量的相關(guān)事件信息。

5.3 測試總結(jié)

此系統(tǒng)能夠良好地利用對(duì)象存儲(chǔ)系統(tǒng)的優(yōu)勢收集和存儲(chǔ)系統(tǒng)內(nèi)核部分的溯源信息、文件格式分析以及文件變更時(shí)間等溯源信息，并在使用audit對(duì)Postmark和內(nèi)核編譯等應(yīng)用程序的溯源收集方面具有較低的時(shí)間和空間開銷，以及較好的查詢性能。

6 結(jié)束語

本文利用對(duì)象存儲(chǔ)系統(tǒng)在對(duì)文件存儲(chǔ)時(shí)的高效性與可擴(kuò)展性，對(duì)系統(tǒng)內(nèi)核、文件屬性（例如文件格式）以及各種應(yīng)用程序的溯源信息進(jìn)行了收集、存儲(chǔ)與查詢研究。

在未來的研究工作中，將在以下方面進(jìn)行加強(qiáng)：

（1）目前能夠得到的內(nèi)核信息僅限于Linux系統(tǒng)下的封裝結(jié)構(gòu)，而且所獲得的內(nèi)容較為單一，值得繼續(xù)豐富此系統(tǒng)內(nèi)核信息結(jié)構(gòu)。

（2）文件格式分析工具目前尚能做到收集文件格式信息并將其展示給需要查詢的用戶，但不能做到對(duì)查詢結(jié)果的存儲(chǔ)操作。由于工具本身屬于Java程序，在Berkeley DB中存儲(chǔ)的方式尚有不同，這也是值得改進(jìn)的地方。

（3）審計(jì)功能由于溯源系統(tǒng)本身不支持，無法做到日志文件存儲(chǔ)操作，但若將溯源系統(tǒng)的可擴(kuò)展的內(nèi)核版本更新到最近的版本，便可以對(duì)日志文件進(jìn)行查詢與處理操作。

另外，將對(duì)如何利用對(duì)象存儲(chǔ)系統(tǒng)中的溯源信息進(jìn)行數(shù)據(jù)重建、智能的管理調(diào)度等開展相關(guān)研究。

[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.

附中文參考文獻(xiàn)：

[1]謝雨來.溯源的高效存儲(chǔ)管理及在安全方面的應(yīng)用研究[D].武漢:華中科技大學(xué),2013.

[19]劉景寧,謝黎明,馮丹,等.對(duì)象存儲(chǔ)設(shè)備端數(shù)據(jù)管理策略研究[J].計(jì)算機(jī)研究與發(fā)展,2010,47(10):1832-1839.