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

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

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

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

1 引言

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

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

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

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

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

（1）不同粒度不同大小的溯源信息可以封裝為對象信息進行存儲。

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

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

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

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

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

2 研究背景

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

（1）實驗文檔

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

①實驗細節(jié)再現(xiàn)

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

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

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

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

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

（3）安全

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

（4）搜索

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

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

目前，國內(nèi)外已經(jīng)研究出了多種溯源存儲系統(tǒng)。這些系統(tǒng)都利用監(jiān)控系統(tǒng)調(diào)用來對文件依賴關(guān)系的信息進行收集。例如，在應(yīng)用層進行收集的SPADE（support for provenance auditing in distributed environments）[15]和 Story Book[16]，在內(nèi)核態(tài)進行收集的PASS[8]和LinFS（lineage file system）[17]。有的系統(tǒng)只能在本地進行收集，如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)一個進程P讀取文件A時，觀察層就會產(chǎn)生一條溯源記錄“P→A”，表示P是依賴于A的。

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）對象的概念

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

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

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

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

（3）對象命令流程

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

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

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

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

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

3.3 溯源信息收集

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

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

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

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

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

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

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

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

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

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

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

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

3.4 溯源存儲和查詢

以內(nèi)核信息為例，溯源存儲以及溯源查詢實現(xiàn)方式如下：在對象存儲客戶端收集內(nèi)核信息后，調(diào)用對象創(chuàng)建命令osd_create_and_write()在設(shè)備端創(chuàng)建一個文件對象，并將所獲取的系統(tǒng)內(nèi)核溯源信息傳輸?shù)皆撐募ο笾小Ｈ缓蠓治龃宋募ο笾械淖址瑢⑹鬃址到y(tǒng)名稱sysname作為數(shù)據(jù)庫的key，將多項溯源信息作為data存儲到Berkeley DB所創(chuàng)建的數(shù)據(jù)庫中。

Berkeley DB[24]是一個主要應(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）兩部分。因此在存儲溯源信息的時候能夠快捷存儲多條信息，而不用經(jīng)過繁雜的創(chuàng)建多表的過程。

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

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

當(dāng)前系統(tǒng)中的重要溯源信息包括操作系統(tǒng)的名稱（sysname）、網(wǎng)絡(luò)結(jié)點名（nodename）、內(nèi)核發(fā)行級別（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]是一個由哈佛大學(xué)研發(fā)的能夠分析文件格式的應(yīng)用程序，在此系統(tǒng)中利用此應(yīng)用程序作為溯源信息的輔助分析工具來幫助得到文件的有效信息。JHOVE提供了去識別格式，認證有效和描述數(shù)據(jù)對象的函數(shù)。格式識別是確定數(shù)據(jù)對象到底遵從哪個數(shù)據(jù)格式的過程，例如“現(xiàn)在有個數(shù)據(jù)對象，它的格式是什么？”格式認證是確定一個數(shù)據(jù)對象遵從的格式的級別，例如“有個格式級別為F的數(shù)據(jù)對象，對嗎？”格式描述是確定一個已給格式的對象的重要詳細特性，例如“有個格式為F的對象，它的重要特性有哪些？”在常規(guī)的數(shù)據(jù)存儲操作中這3個函數(shù)都是十分必要的。

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

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

JHOVE是一個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超文本標記語言、JPEG-hul聯(lián)合圖像壓縮文件、PDF-hul便攜式文檔、TIFF-hul標簽圖像文件、UTF8-hul UTF8編碼文件、WAVE Windows下的音頻文件、XML-hul可擴展標記語言等。

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

調(diào)用JHOVE時利用創(chuàng)建管道的方式調(diào)用Linux命令行來編譯運行。同時這個管道由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”)，同時關(guān)閉管道的函數(shù)為pclose(pFile)。這樣便可利用系統(tǒng)分析得到文件的基本格式以及創(chuàng)建變更日期等溯源信息。

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

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

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

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

# vi test.txt

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

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

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

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

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

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

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

4.4 存儲和查詢溯源信息

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

（1）存儲流程

利用對象創(chuàng)建和寫命令將在客戶端收集的內(nèi)核溯源信息寫入到設(shè)備端的對象文件中。然后在設(shè)備端首先創(chuàng)建一個名為sysDB.db的數(shù)據(jù)庫，并且打開已存儲系統(tǒng)內(nèi)核信息的對象文件，將對象文件中的內(nèi)容按分號為結(jié)束標識來讀取每一條系統(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ù)據(jù)，最后利用db_close()函數(shù)來關(guān)閉數(shù)據(jù)庫。值得注意的是每一條內(nèi)核信息長度都是不一樣，因此在存儲的時候需要通過動態(tài)分配的方式，得到每一條信息的準確長度，在磁盤上不留無用空間。

（2）查詢流程

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

5 系統(tǒ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)中進行。而審計功能則在Ubuntu14.04，內(nèi)核版本為3.19.0-25的Linux系統(tǒng)中進行。以上兩個系統(tǒng)均為macOS系統(tǒng)下利用VirtualBox軟件所搭建的虛 擬機平臺。macOS系統(tǒng)版本號為10.11.5，CPU型號為2.7 GHz Intel Core i5。

5.2 評估結(jié)果

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

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

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

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

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

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

對文本文件進行格式分析，此文本文件為根目錄下的readresult.txt文件，分析出格式為字符流式文件，依照的標準為2007-4-10發(fā)布的1.3版本。而文件本身的最近更改時間為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審計規(guī)則和監(jiān)控觀察器的建立，對/etc/audit/auditd.conf文件進行設(shè)置，同時確定是否循環(huán)使用日志文件。同時它還能夠配置審計規(guī)則記錄更詳細的信息，設(shè)置日志文件位置log_file=/var/log/audit/test.log。設(shè)置的重要信息如表4所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（4）溯源查詢性能

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

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

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

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

5.3 測試總結(jié)

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

6 結(jié)束語

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

在未來的研究工作中，將在以下方面進行加強：

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

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

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

另外，將對如何利用對象存儲系統(tǒng)中的溯源信息進行數(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.

附中文參考文獻：

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

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