專利名稱：事務(wù)文件系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明一般針對計算機和文件系統(tǒng)。
背景技術(shù)：
通常的文件系統(tǒng)提供操縱文件層次結(jié)構(gòu)的機制，包括建立新的文件或目錄，刪除或重命名文件或目錄，和對文件內(nèi)容的操作。某些文件系統(tǒng)提供有關(guān)單個低級操作(即原語)的完整性的確定保證。例如，建立新文件的原語或者是成功地完成，或者該建立文件操作的任意部分作用被系統(tǒng)撤消。
然而，在用戶級的多穩(wěn)健系統(tǒng)的操作卻沒有與該文件系統(tǒng)有聯(lián)系。例如，對于一個文件系統(tǒng)現(xiàn)在沒有方法建立四個文件，刪除三個其他文件并改名另外的文件，但如果這些操作中的任一個失敗，就撤消任何其他操作。因此，要使用如應(yīng)用程序這樣的更高級(用戶級)處理來管理這種多操作，即對該文件系統(tǒng)指定哪個動作可應(yīng)用于哪個文件和/或目錄。
然而，此解決方法有其本身的缺陷?？紤]一個例子，其中一個網(wǎng)站具有20個網(wǎng)頁，以給予此網(wǎng)站一致的外觀及感覺的方法彼此鏈接。在更新該網(wǎng)站時，系統(tǒng)失敗導(dǎo)致不一致的狀態(tài)。例如，執(zhí)行更新的應(yīng)用程序可以已刪除了某些文件但在失敗時未刪除來自其他文件指向這些文件的鏈接。一個觀看此網(wǎng)站的用戶將看到某些網(wǎng)頁，而當點擊與已刪除網(wǎng)頁的鏈接時會收到的錯誤的消息。
為防止引起在不一致狀態(tài)的可能性，在層次結(jié)構(gòu)中的任何文件被改變之前整個網(wǎng)頁的文件層次通常已經(jīng)進行復(fù)制。在發(fā)生失敗時，被保存的層次結(jié)構(gòu)復(fù)制回來。然而，文件的這種復(fù)制是慢的，而且相對笨拙，因為復(fù)制程序需要事先知道系統(tǒng)哪個部分將要更新，且易于出錯，因為如果任何文件被疏忽而未復(fù)制，它就不能再恢復(fù)。
如果文件在使用更高級的處理以更新文件時進行適當改變的話，則任何在進行中的改變?yōu)橛^看此網(wǎng)站的用戶可見。例如，對于上述的網(wǎng)站，在文件(和名字層次結(jié)構(gòu))由應(yīng)用程序改變時，任何改變對該系統(tǒng)的現(xiàn)有用戶是可見的。因為在所有改變完成以前系統(tǒng)狀態(tài)通常是不一致的，因此，用戶可以看到此不一致性。例如，當出現(xiàn)應(yīng)用程序已刪除一個網(wǎng)頁但尚未去除指向該頁的鏈接的情況時，現(xiàn)有的用戶可以在網(wǎng)頁上看到一個鏈接(URL)，點擊它并在已被刪除的網(wǎng)頁上結(jié)束。
除了網(wǎng)頁更新以外，其他程序在它們一致地保存信息方面的能力中也受到類似的限制。例如，典型的文字處理應(yīng)用程序或電子表格應(yīng)用程序通過改名和刪除操作執(zhí)行所有保存，使用臨時文件以防止引起后續(xù)系統(tǒng)失敗的不一致狀態(tài)。這種應(yīng)用程序也可以需要在不同數(shù)據(jù)源之間分配信息。例如，應(yīng)用程序可能希望在SQL Server中存儲表格數(shù)據(jù)，在文件服務(wù)器和/或在因特網(wǎng)服務(wù)器中存儲文件，例如，這種文件可以包括文字處理文檔、演示圖表和/或網(wǎng)頁。但是，現(xiàn)在并不存在一種機制以協(xié)調(diào)一致、統(tǒng)一的方式支持這種信息的保存。例如，若在保存這種信息期間系統(tǒng)失敗，將保存某些信息，而其他則不保存，再次導(dǎo)致不一致狀態(tài)。

發(fā)明內(nèi)容
簡而言之，本發(fā)明提供一種系統(tǒng)和方法，通過本發(fā)明多文件系統(tǒng)操作能作為單個用戶級事務(wù)的部分執(zhí)行。本發(fā)明的事務(wù)文件系統(tǒng)使用戶能可選地控制在文件系統(tǒng)中事務(wù)的范圍(context)和.持續(xù)時間。
在文件打開或建立期間，應(yīng)用程序規(guī)定文件打開情況的操作是否應(yīng)作為事務(wù)的一部分處理。此外，系統(tǒng)有能力永久性地標記只能被事務(wù)性地操作的文件，而應(yīng)用程序在打開/建立的時間通過全局唯一的id(GUID)指定該事務(wù)。對于新文件建立，其父目錄被標記為事務(wù)處理的，而應(yīng)用程序能將一個事務(wù)與線程/處理相關(guān)聯(lián)，從而通過這種線程/處理的文件操作在指定的事務(wù)的范圍內(nèi)進行事務(wù)處理。此外，應(yīng)用程序可選擇(如通過API)指令系統(tǒng)子線程/處理繼承事務(wù)的上下文關(guān)系，使應(yīng)用程序能利用事務(wù)而不必對應(yīng)用程序源代碼作任何明顯的修改。
一旦事務(wù)性地打開文件，系統(tǒng)自動地包括在文件處理上的如讀、寫、刪除或改名操作，作為事務(wù)的一部分。因此，應(yīng)用程序能調(diào)用現(xiàn)有的文件系統(tǒng)API，繼續(xù)查看現(xiàn)有的每次操作的語義，還將操作作為事務(wù)的一部分包括起來。一個應(yīng)用程序能夠自由地想用多少事務(wù)就用多少，自由地與其他應(yīng)用程序共享一個事務(wù)，具有同樣多的線程/處理共享一個事務(wù)等。對駐留在不同機器上的文件所做的文件打開指定該事務(wù)。
本發(fā)明的其他方面針對記錄，使得能從失敗的事務(wù)恢復(fù)。在事務(wù)下，如果事務(wù)由于包括系統(tǒng)失敗和應(yīng)用程序失敗等任何原因而失敗，由系統(tǒng)作出的改變撤消，而且如果系統(tǒng)成功地提交代表該應(yīng)用程序的事務(wù)，則由系統(tǒng)對該事務(wù)作出的改變保證能經(jīng)受得住系統(tǒng)失敗(如電源斷電)。這是借助多級記錄機制和另一個機制實現(xiàn)的，所述另一種機制對低級記錄操作是否被成功地提交進行判定，從而確定較高級記錄操作是否實際上發(fā)生。
通過將操作事件分隔成一個日志，并且將事務(wù)的實際數(shù)據(jù)寫入細節(jié)分隔到另一個中，來記錄數(shù)據(jù)的改變。一個機制寫入一個簽名并隨后將其與已記錄的日志及數(shù)據(jù)一起比較以判定已記錄的日志是否與其相應(yīng)的數(shù)據(jù)頁同步，消除了將該日志以相對于數(shù)據(jù)的特定次序?qū)懭氡P中的要求。
本發(fā)明的另外方面包括在事務(wù)和其他文件系統(tǒng)操作之間提供名字空間和文件數(shù)據(jù)的隔離。名字空間隔離借助使用隔離目錄實現(xiàn)，以跟蹤哪個名字屬于哪個事務(wù)。因此，對給定事務(wù)由系統(tǒng)作出的變化對其他事務(wù)不可見，而且修改事務(wù)仍然有效，且只有在修蓋事務(wù)成功地提交后成為可見。事務(wù)未覺察的文件句柄在變化發(fā)生時看到所述改變。因此，在第一事務(wù)過程中刪除的文件將不再被該第一事務(wù)看到或沒有事務(wù)會看到，但在第一事務(wù)完成之前對其他事務(wù)仍然可見。
為實現(xiàn)這種名字空間隔離，建立隔離目錄，它們鏈接到原始NTFS目錄，并將適當?shù)奈募旨拥皆摳綦x目錄以替代普通的NTFS父目錄。例如，對于刪除操作，被刪除文件的名字在文件從NTFS父目錄中除去的同時被加到該隔離目錄。在提交以前，隨后由不同的事務(wù)對此文件的訪問使用隔離目錄來應(yīng)付，因此該文件被找到并認為未被刪除。類似地，如果一個事務(wù)建立一個文件，名字被加到NTFS目錄以及鏈接到父NTFS目錄的隔離目錄。建立該文件的事務(wù)能看到它，但對于其他事務(wù)，該名字針對打開此文件和列出父NTFS目錄的目的而被濾去。當事務(wù)提交或中斷時，隔離目錄項從該隔離目錄中被去除。
因此，本發(fā)明加入事務(wù)機制到文件系統(tǒng)中，使得應(yīng)用程序能容易執(zhí)行對一個或多個文件的多重事務(wù)操作，克服了與外事務(wù)機制相關(guān)的問題。以這樣的方法，在文件系統(tǒng)中多個文件系統(tǒng)的操作以事務(wù)方式互相聯(lián)系，這樣，這些操作要么一起提交，要么就撤消任何部分的動作。此外，一個事務(wù)的操作和數(shù)據(jù)改變與另一事務(wù)的操作和數(shù)據(jù)相隔離。
從下面結(jié)合附圖的詳細描述中，其它的優(yōu)點變得顯而易見。
附圖簡述

圖1是方框圖，表示可以加入本發(fā)明的一個計算機系統(tǒng)；圖2是方框圖，表示按本發(fā)明的一個方面實現(xiàn)事務(wù)文件系統(tǒng)的通用結(jié)構(gòu)；圖3是方框圖，表示按本發(fā)明的一個方面建立/打開一個事務(wù)文件的請求；圖4是方框圖，表示按本發(fā)明的一個方面在一個打開事務(wù)文件上執(zhí)行一個文件系統(tǒng)操作的請求。
圖5是方框圖，表示按本發(fā)明的一個方面在一個時間周期上事務(wù)文件的隔離；圖6是方框圖，表示按本發(fā)明的一個方面跟蹤文件版本的數(shù)據(jù)結(jié)構(gòu)；圖7是方框圖，表示按本發(fā)明的一個方面隨時間維持多個文件版本；圖8是方框圖，表示為寫入而事務(wù)性打開的文件的數(shù)據(jù)頁；圖9-10是方框圖，表示按本發(fā)明的一個方面用于支持為在事務(wù)中讀和寫而打開的文件的隔離的數(shù)據(jù)結(jié)構(gòu)之間的關(guān)系；圖11是方框圖，表示按本發(fā)明的一個方面的兩級記錄機制和驗證這些日志是否同步的機制；圖12是方框圖，表示按本發(fā)明的一個方面所記錄的頁數(shù)據(jù)和驗證該頁數(shù)據(jù)是否與日志同步的機制；圖13是流程圖，表示按本發(fā)明的一個方面根據(jù)頁數(shù)據(jù)是否與所記錄的日志同步而采取的動作；圖14是方框圖，表示按本發(fā)明的一個方面在另外的版本方案中隨時間維持多個文件版本；圖15是方框圖，表示按本發(fā)明的一個方面在網(wǎng)絡(luò)上的事務(wù)文件系統(tǒng)操作；圖16-18是方框圖，表示按本發(fā)明的一個方面的層次文件結(jié)構(gòu)和使用隔離目錄提供名字空間隔離；圖19-22是流程圖，表示按本發(fā)明的一個方面為提供名字空間隔離而使用隔離目錄的一般規(guī)則；和圖23是方塊圖，表示按本發(fā)明的一個方面存儲器映射段的浮動。
具體實施例方式
圖1和下面討論試圖提供可應(yīng)用本發(fā)明的適合的計算環(huán)境的簡明描述。雖然并非必要，但本發(fā)明以計算機可執(zhí)行指令的一般上下文范圍中描述，如由個人計算機執(zhí)行的程序模塊。通常，程序模塊包括例行程序、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等，它們執(zhí)行特定的任務(wù)或?qū)崿F(xiàn)特定的抽象數(shù)據(jù)類型。
此外，本領(lǐng)域熟練人員知道，本發(fā)明可以應(yīng)用其他計算機系統(tǒng)配置來實現(xiàn)，包括手持式裝置、多處理器系統(tǒng)、基于微處理器或可編程消費者電子設(shè)備、網(wǎng)絡(luò)PC、小型計算機、大型主機等。本發(fā)明也能在分布式計算環(huán)境中實現(xiàn)，其中任務(wù)由通過通信網(wǎng)落鏈接的遠程處理設(shè)備執(zhí)行。在分布式計算機環(huán)境中，程序模塊可以放置在本地或遠程的存儲器儲存設(shè)備中，參考圖1，實現(xiàn)本發(fā)明的一個示例性系統(tǒng)包括以傳統(tǒng)的個人計算機20或類似形式的通用計算設(shè)備，它包括處理單元21、系統(tǒng)存儲器22和耦合包括系統(tǒng)存儲器的各種系統(tǒng)部件到處理單元21的系統(tǒng)總線23。系統(tǒng)總線23可以是若干類型總線結(jié)構(gòu)的任一種，包括存儲器總線或存儲器控制器、外圍總線和使用各種總線結(jié)構(gòu)的任一種的局部總線。系統(tǒng)存儲器包括只讀存儲器(ROM)24和隨機存取存儲器(RAM)25。在ROM 24中存儲基本輸入/輸出系統(tǒng)26(BIOS)，它包括基本的例行程序，以幫助如在起動過程中在個人計算機20中各單元之間傳遞信息。個人計算機20還可以包括硬盤驅(qū)動器27，用于向硬盤(未示出)讀和寫；磁盤驅(qū)動器28，用于可向可移動磁盤29的讀和寫；和光盤驅(qū)動器30用于向如CD-ROM或其他光媒體之類的可移動光盤31的讀和寫。硬盤驅(qū)動器27、磁盤驅(qū)動器28和光盤驅(qū)動器30分別通過硬盤驅(qū)動器接口32，磁盤驅(qū)動器接口33和光驅(qū)動器接口34連接到系統(tǒng)總線23。這些驅(qū)動器和與其相關(guān)的計算機可讀媒體提供計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊和用于個人計算機20的其他數(shù)據(jù)的非易失性存儲。雖然這里描述的示例性環(huán)境使用了硬盤、可移動磁盤29和可移動光盤31，本專業(yè)中熟悉人員應(yīng)理解，能儲存由計算機可訪問的數(shù)據(jù)的其他類型計算機可讀媒體在示例性操作環(huán)境中也能使用，如盒式磁帶、閃存卡、數(shù)字視頻盤、Bernoulli盒式盤帶，隨機存儲器(RAM)，只讀存儲器(ROM)等。
包括操作系統(tǒng)35(最好是微軟公司的Windows2000，以前的WindowsNT)在內(nèi)的許多程序模塊能存入硬盤、磁盤29、光盤31、ROM 24或RAM 25。計算機20包括與操作系統(tǒng)35相關(guān)或包括在其中的文件系統(tǒng)36，如Windows NT文件系統(tǒng)(NTFS)、一個或多個應(yīng)用程序37、其他程序模塊38和程序數(shù)據(jù)39。用戶能通過如鍵盤40和指示設(shè)備42之類的輸入設(shè)備將命令和信息輸入到個人計算機20中。其他輸入設(shè)備(未示出)可以包括麥克風(fēng)、游戲桿、游戲板、衛(wèi)星碟(satellite disk)、掃描器等。這些及其他輸入設(shè)備通常通過耦合到系統(tǒng)總線的串口接口46連接到處理單元21，但也能通過如并行端口、游戲端口或通用串口總線(USB)之類的其他接口連接。監(jiān)視47或其他類型的顯示設(shè)備也能通過如視頻適配器48這種接口連接到系統(tǒng)總線23。除了監(jiān)視器47外，個人計算機通常包括其他外圍輸出設(shè)備(未示出)，如揚聲器和打印機。
個人計算機20可使用與如遠程計算機49之類的一個或多個遠程計算機的邏輯連接在網(wǎng)絡(luò)環(huán)境中運行。遠程計算機49可以是另一個人計算機、服務(wù)器、路由器、網(wǎng)絡(luò)PC、對等設(shè)備或其他常用的網(wǎng)絡(luò)節(jié)點，而且雖然在圖1中只示出存儲器存儲設(shè)備50，但通常包括許多或所有上述與個人計算機20相關(guān)的單元。在圖1畫出的邏輯連接包括局域網(wǎng)(LAN)51和廣域網(wǎng)(WAN)52。這種網(wǎng)絡(luò)環(huán)境在辦公室、企業(yè)范圍計算機網(wǎng)絡(luò)、企業(yè)網(wǎng)和因特網(wǎng)中是常見的。
當在LAN網(wǎng)絡(luò)環(huán)境中使用時，個人計算機20通過網(wǎng)絡(luò)接口或適配器53連到局域網(wǎng)51。當在WAN網(wǎng)絡(luò)環(huán)境使用時，個人計算機20通常包括調(diào)制解調(diào)器54或其他用于在如因特網(wǎng)之類的廣域網(wǎng)52上建立通信的裝置。調(diào)制解調(diào)器54(可以是內(nèi)制或外制式的)通過串口接口46連接到系統(tǒng)總線23。在網(wǎng)絡(luò)環(huán)境中，相對于個人計算機20所描述的程序模塊或其一部分可以儲存在遠程存儲器存儲設(shè)備中。應(yīng)該明白，示出的網(wǎng)絡(luò)連接是示例性的，可以使用在計算機之間建立通信鏈路的其他方法。
雖然本發(fā)明是相對于Windows2000操作系統(tǒng)和微軟的Windows NT文件系統(tǒng)(NTFS)描述，本專業(yè)熟悉人員明白，也能使用其他操作系統(tǒng)和/或文件系統(tǒng)，并從本發(fā)明中得益。
事務(wù)文件系統(tǒng)的通用結(jié)構(gòu)通常，這里使用的術(shù)語“事務(wù)”、“事務(wù)的”等被認為是具有某些共同屬性的操作，在本發(fā)明中是應(yīng)用于多重文件系統(tǒng)的操作。事務(wù)屬性常稱之為“ACID”屬性，代表著原子性、一致性、隔離性和持續(xù)性。如在下面所理解，本發(fā)明實現(xiàn)了與文件系統(tǒng)相關(guān)的這些屬性，為應(yīng)用程序和一般計算提供許多益處。
如在圖2中通常所示，從應(yīng)用程序60等所發(fā)出的給如微軟Windows NT文件系統(tǒng)(NTFS)36(圖1)這種事務(wù)啟用文件系統(tǒng)62(如這里相對于本發(fā)明敘述)的文件系統(tǒng)請求58，經(jīng)過分派機制66達到NTFS部件64。對于傳統(tǒng)的文件系統(tǒng)已經(jīng)知道，為了產(chǎn)生例如可以導(dǎo)致由I/O管理器發(fā)送到文件系統(tǒng)的I/O請求包(IRP)的這些請求，應(yīng)用程序60可以作出應(yīng)用程序接口(API)調(diào)用。按本發(fā)明并如下所述，文件系統(tǒng)請求58的某些與事務(wù)相關(guān)，而其他則不是。
在沒有事務(wù)情況，文件系統(tǒng)請求58被分派并直接由NTFS部件64處理，實際上用本發(fā)明以前的方法。類似地，由事務(wù)發(fā)出的或指向如下述被打開事務(wù)修改過的文件或目錄的請求58也繼續(xù)正常分派到NTFS部件64，或從NTFS部件分派。但是，這種事務(wù)請求導(dǎo)致在其他正常處理期間的策略點處調(diào)出(調(diào)回)到如在文件系統(tǒng)62內(nèi)部實現(xiàn)的TxF部件70。
如圖2所示并如下所述，TxF部件70包括到外部事務(wù)服務(wù)72和記錄服務(wù)74的接口，并與NTFS部件64一起工作處理事務(wù)請求。外部事務(wù)服務(wù)72可以包括微軟公司的分布式事務(wù)協(xié)調(diào)程序(MS DTC，或簡稱為MTC或DTC)，其中一個客戶(如應(yīng)用程序60)調(diào)用啟用一個事務(wù)，隨后的調(diào)用提交或中斷該操作。DTC有文檔已很好描述，在這里只作簡單說明而不作詳細描述，且說明范圍只限于與TxF 70相關(guān)的部分。
通常如圖3所示，在MS DTC中，經(jīng)過COM/DLE如應(yīng)用程序60這樣的應(yīng)用程序借助調(diào)用事務(wù)協(xié)調(diào)程序76(圖3)的方法(即BeginTransaction方法)啟用事務(wù)。事務(wù)協(xié)調(diào)程序76可以是網(wǎng)絡(luò)中的事務(wù)服務(wù)器或其本地的代理。此調(diào)用建立了代表事務(wù)的事務(wù)對象/范圍78。然后應(yīng)用程序60調(diào)用一個或多個資源管理器做事務(wù)工作。在本發(fā)明中，TxF部件70作為了用于事務(wù)文件系統(tǒng)操作的資源管理器。在圖3所示及下面描述中，對文件系統(tǒng)62的API調(diào)用(如CreateFileEx 80和其他文件系統(tǒng)操作)產(chǎn)生調(diào)出到TxF部件70。
應(yīng)用程序?qū)ξ募到y(tǒng)62的第一次調(diào)用是對文件、目錄或具有與其相關(guān)的事務(wù)范圍78的應(yīng)用程序的當前的線程/過程的識別。如果事務(wù)范圍是相關(guān)的，文件系統(tǒng)62調(diào)出到TxF 70。當TxF 70首次代表事務(wù)執(zhí)行工作時，它通過調(diào)用事務(wù)協(xié)調(diào)程序76列入該事務(wù)，然后通知事務(wù)協(xié)調(diào)程序76該TxF 70是在此事務(wù)中用到的資源管理器。注意，其他資源管理器84(如數(shù)據(jù)庫部件的資源管理器)也能類似地列入此事務(wù)，因而數(shù)據(jù)庫的操作和文件系統(tǒng)的操作能在同一事務(wù)中一起提交(或中斷)。
為了判斷什么時候TxF 70需要列入事務(wù)，如圖3所示使用與ITransaction對象78一起進入的事務(wù)標識符(ID)，TxF部件70的事務(wù)管理器82層將ID與事務(wù)ID的事務(wù)表86中保持的已知列入的事務(wù)進行校驗。如果已經(jīng)列入，事務(wù)ID和事務(wù)參照被記錄在I/O請求包(IRP)中，而IRP繼續(xù)。IRP在NTFS中的使用有文檔已很好描述，為簡單起見在后面不再描述。但是，如果該事務(wù)未被列入表86中，TxF通知事務(wù)協(xié)調(diào)程序76TxF 70是需要與此事務(wù)關(guān)聯(lián)的資源管理器，并將該事務(wù)標識符存入獲得的事務(wù)表86中。
更具體說來，當事務(wù)是未列入表86的新事務(wù)時，需要用事務(wù)協(xié)調(diào)程序76列入。為此，TxF管理器82采用代理88使用OLE事務(wù)或其他協(xié)議與事務(wù)協(xié)調(diào)程序76通信。適合本發(fā)明使用的替代協(xié)議等包括(X/OPEN的)XA，TIP(事務(wù)因特網(wǎng)協(xié)議)和/或在操作系統(tǒng)中的內(nèi)在事務(wù)控制。Create FileEX 80請求將ITransaction對象78(如通過DTC ItransactionTransmitter方法)安排到統(tǒng)一的字節(jié)集合。如果需要列入，這些字節(jié)發(fā)送到代理器88，它轉(zhuǎn)而調(diào)用DTC ItransactionReveiver方法取回列入需要的ITransaction對象78。代理88保持DTC對象的ITransactionResourceAsync和ITransactionEnlistmentAsync。ITransactionResourceAsync應(yīng)用TxF回調(diào)例行程序，使得事務(wù)協(xié)調(diào)程序76調(diào)用驅(qū)動二階段提交，并具有列入調(diào)用。ItransactionEnlistmentAsyc通過IResourceManage∷enlist()返回，并包含TxF 70調(diào)用確認二階段提交控制的方法。代理88作為在ItransactionResourceAsync和ItransactionEnlistmentAsync及基于文件系統(tǒng)控制(FSCTL)遠程程序調(diào)用(RPC)的方法之間的中介，而RPC用于在TxF部件82和代理88之間的通信。
注意，具有以與DTC協(xié)調(diào)程序過程同樣的過程運行的TxF調(diào)協(xié)程序代理是可行的，且將事務(wù)管理器移到核心程序中以消除過程切換額外開銷也是可行的。DTC代理的占位程序(Stub)也能移到核心程序中使得在建立用戶模式代理中不需要TxF工作，同時也消除了從TxF代理到事務(wù)管理器的切換。TxF代理能以與DTC協(xié)調(diào)程序同樣的過程運行，后者需要由TxF代理工作，但是其具有與以前解決方案相同數(shù)目的過程切換。
列入以后，當事務(wù)進行時，事務(wù)協(xié)調(diào)程序76保持對包括列入在事務(wù)中的TxF 70的每個資源管理器(和可能其他資源管理器84，如其他的TxF或數(shù)據(jù)庫資源管理器)的跟蹤。注意，這就使得其他信息(如數(shù)據(jù)庫信息)作為還提交文件系統(tǒng)信息的事務(wù)的一部分被提交，而且使得多重事務(wù)啟用文件系統(tǒng)的文件(如在遠程機器上)作為同一事務(wù)的一部分被提交。
通常，應(yīng)用程序60借助調(diào)用(通過COM)事務(wù)協(xié)調(diào)程序76的提交事務(wù)方法來完成該事務(wù)以提交該事務(wù)。事務(wù)協(xié)調(diào)程序76隨后通過二階段提交協(xié)議使每個列入的資源管理器得以提交。二階段提交協(xié)議保證所有資源提交該事務(wù)，或均中斷該事務(wù)。在第一階段，事務(wù)協(xié)調(diào)程序76詢問包括TxF部件70的每個資源管理器，是否準備提交。如果這些資源管理器肯定地響應(yīng)，則在第二階段，事務(wù)協(xié)調(diào)程序76向它們廣播一個提交消息。如果任何一個資源服務(wù)器否定地響應(yīng)，或未能響應(yīng)此準備請求，和/或事務(wù)任何部分失敗，則事務(wù)協(xié)調(diào)程序76通知資源管理器，事務(wù)中斷。而且，如果應(yīng)用程序不能完成，應(yīng)用程序60調(diào)用中斷事務(wù)方法。如果應(yīng)用程序失敗，事務(wù)協(xié)調(diào)程序76代表應(yīng)用程序中斷該事務(wù)。如下所述，包括TxF 70的各種資源管理器就撤消任何部分動作。
因此，TxF部件70就作為在標準事務(wù)服務(wù)(如DTC)的范圍中的資源管理器，因而真正的用戶定義的事務(wù)支撐擴展到文件系統(tǒng)。注意，如下所述，NTFS允許TxF將瞬態(tài)的每個文件和每個流的事務(wù)狀態(tài)鏈接到正常的NTFS結(jié)構(gòu)。
按照本發(fā)明的一個方面，應(yīng)用程序60可選擇包括在一個事務(wù)中的文件系統(tǒng)操作。這可對每個文件實現(xiàn)，使得每個文件標記為經(jīng)事務(wù)處理的，且這種的操作按事務(wù)方式完成，或者對每個線程/過程實現(xiàn)，其中線程/過程標記為經(jīng)事務(wù)處理的，而由該線程/過程所作的操作按事務(wù)方式完成。
為了在一個事務(wù)中包括在一個文件，定義一個事務(wù)處理模式標志(即位)，它能與CreateFileEx應(yīng)用程序編程接口(API)調(diào)用(下面描述)、CreateFile WIN32 API變化的一起使用。當設(shè)置標志時，本發(fā)明的系統(tǒng)自動將此文件包括在事務(wù)的范圍中。為此，如在圖3中表示，當通過I/O請求包(IRP)，一個建立請求80進入文件系統(tǒng)(NTFS)62時，現(xiàn)有的事務(wù)范圍78可以通過將一指針轉(zhuǎn)到該范圍78而附加到該請求上，從而該文件能作為現(xiàn)有事務(wù)范圍78的一部分被建立/打開?；蛘撸绻贑reateFileEx API調(diào)用中指向Itransaction指針的指針是空，就如在MicrosoftTransaction Server(MTS)/Component Object Model(com)模型中那樣，該范圍被自動地挑選出到該線程之外。響應(yīng)成功地建立/打開請求80而返回的文件句柄90包括到該事務(wù)范圍78的指針。然后，用那個句柄90作出的調(diào)用通過此指針識別為具有與其關(guān)聯(lián)的事務(wù)范圍，由此識別出相關(guān)的事務(wù)，而且使用該句柄的文件系統(tǒng)操作代表該事務(wù)被執(zhí)行，直到該事務(wù)結(jié)束。
CreateFileEx API是現(xiàn)有的CreateFile Win32 API的適當擴展集，并加上″dwAdditionalFlags″DWORD參數(shù)以取得標志″FILE_FLAG_TRANSACTED″來設(shè)置該事務(wù)的模式。還定義的是指向事務(wù)范圍的對象(LPUNKNOWNpunkTrasction)的參數(shù)，如上所述，如果參數(shù)為空，該對象就從當前的MTS/COM范圍中挑出。
為了標記一個線程/過程為經(jīng)事務(wù)處理的，提供SetTransactedFiles API，它有效地處理一組CreateFile/CreateFileEx調(diào)用，好象它們對經(jīng)事務(wù)處理模式標志設(shè)定。如果特定的CreateFileEx指定非空ITransaction對象指針，該對象用作事務(wù)范圍78，否則該MTS事務(wù)對象被挑出該線程。
使用SetTransactedFiles API將線程/過程標記為經(jīng)事務(wù)處理的，從而通過該線程/過程的任何文件系統(tǒng)訪問都是經(jīng)事務(wù)處理的。能設(shè)置三個不同的標志，即一個在設(shè)置時導(dǎo)致從當前線程的任何文件系統(tǒng)訪問都成為經(jīng)事務(wù)處理的標志；一個在設(shè)置時導(dǎo)致從當前過程中每個線程的任何文件系統(tǒng)訪問都成為經(jīng)事務(wù)處理的標志；以及一個在設(shè)置時導(dǎo)致從當前過程衍生的子過程對這些標志的第二和第三個標志進行設(shè)定。因此，有可能以衍生過程繼承這種模式的方式標記該線程/過程，這是一種非常有效的機制，因它允許現(xiàn)有的應(yīng)用程序利用經(jīng)事務(wù)處理的NTFS。此外，它允許應(yīng)用程序作出不具有事務(wù)處理模式位的文件系統(tǒng)操作，如刪除文件和復(fù)制文件。也能將此特征用于允許經(jīng)事務(wù)處理命令行批處理腳本。下面描述SetTransactedFiles APISetTransactedFiles([in]DWORD dwMode，//零或來自列舉的TxFILEMODE更多值。此值//包含對標志的新設(shè)置，它們將按照dwMask//參數(shù)所指示進行設(shè)置。
DWORD dwMask，//零或來自列舉的TxFILEMODE的更多值。只//有出現(xiàn)在此掩碼中的那些標志值會受//SetTransactedFiles調(diào)用的影響。
DWORD*pdwPrevMode，//可選。如果提供，則通過這里，將以//前的模式返回給調(diào)用者。
)；合法的標志值如下Enum TxFILEMODE{TxFILEMODE_THISTHREAD＝0x00000001，//對當前的線程TxFILEMODE_ALLTHREADS＝0x00000002，//對該過程中所有線程TxFILEMODE_CHILDPROCESSES＝0x00000004，//在設(shè)置此模式時//使從當前過程衍//生的所有子過程//自動將_ALLTHREADS//和_CHILDPROCESSES//設(shè)置。
TxFILEMODE_ALL＝0xFFFFFFFF}；如圖4所示，對除建立/打開以外的文件操作，應(yīng)用程序60為文件系統(tǒng)提供句柄90，如通過API調(diào)用92請求文件讀操作，從而通過事務(wù)范圍指針，文件系統(tǒng)能定位事務(wù)范圍。注意，如上所述TxF 70必須列入該事務(wù)。由于在文件句柄90中指出事務(wù)范圍，文件系統(tǒng)就知道此操作包括在事務(wù)之中，并知道特別相關(guān)事務(wù)的標識符。將文件包括在事務(wù)范圍中意味著包括讀、寫、文件建立和刪除的對該文件的操作將經(jīng)事務(wù)處理。任意數(shù)量的文件系統(tǒng)請求可組合在一個事務(wù)內(nèi)并原子地和持續(xù)地提交或中斷。此外，在任何時刻可以進行任意數(shù)量的事務(wù)并互相隔離。
事務(wù)訪問一讀和寫隔離如上所述，為事務(wù)處理的訪問可以打開或建立文件。目前，為了提供直接的、安全的和可預(yù)測的性能，系統(tǒng)將在任意給定時間中在系統(tǒng)中更新(寫)程序事務(wù)數(shù)目限定到1，即如果多個事務(wù)試圖同時打開文件進行讀/寫(RW)訪問，在文件打開時刻就返回一個錯誤。因此，這些限制配置在文件級(相對于流級)。此限制伴隨該文件直至以后提交或中斷。
但是，另外可行的是用更精細的精度實現(xiàn)系統(tǒng)，如文件可以由多個寫入程序打開，但是沒有一個能改寫文件中由另一個程序所寫的(臟(dirty))頁，即一旦某頁被寫過，該頁就被鎖定。而且，“最后-寫入程序-成功”類型的訪問在這里也能實現(xiàn)。注意，在一個給定的系統(tǒng)中這些類型的文件“寫”訪問不是互相排斥的，因為下面情況是可行的，一個API打開一個文件進行寫訪問而鎖定整個文件，另一個API打開一個文件(不是同時鎖定的文件)進行寫訪問而鎖定每頁(或其他文件段)，和/或又一個API是最后-寫入程序-成功寫訪問。然而，這里為了簡單起見，本發(fā)明是以整個文件在給定時刻只能由事務(wù)打開一次(即其他只能順次(serialize)打開)以讀/寫訪問來敘述。文件的非事務(wù)更新程序也可以與用于寫入的事務(wù)打開順序化。注意，這并沒有阻止屬于同一事務(wù)的多個線程同時打開文件以寫入。對于作只讀訪問打開文件的讀程序的數(shù)目未加以嚴格的限制。
繼續(xù)考慮本發(fā)明，由事務(wù)為讀訪問打開的文件與由另外的事務(wù)對此文件作出的同時改變隔離，而不管寫程序是在讀程序之前還是在其后打開該文件。而且，此隔離一直持續(xù)到只讀事務(wù)訪問的結(jié)束而不管改變該文件的事務(wù)是否提交該事務(wù)。例如，如圖5所示，考慮事務(wù)處理讀程序X它打開頁面的文件V0用于只讀訪問，在圖5中在時間軸起點由X/RO表示。注意，文件中每頁的大寫字符“0”表示在打開時間的原始數(shù)據(jù)。如果寫入程序Y在以后時間在另一個事務(wù)中打開文件V1用于讀/寫訪問(Y/RW)，并隨后作出改變(Y/Writes)，事務(wù)處理的讀程序X將繼續(xù)看到在文件V0中的原始數(shù)據(jù)，而不是寫入程序Y在V1中的改變。注意，當發(fā)生改變時，非事務(wù)將看到文件發(fā)生的改變。
如下所述，為了實現(xiàn)事務(wù)的隔離，(至少)在讀程序X使文件打開的時間內(nèi)，為讀程序保留文件的V?！鞍姹尽?。即使當事務(wù)的寫程序Y提交時這仍然保持正確。注意，如下將詳述，寫程序Y對文件本身作出改變，而被讀程序X看到的版本是在寫入改變之前作出的原始數(shù)據(jù)的逐頁復(fù)制；但相反情況也是可行的，即對讀程序x保持原始數(shù)據(jù)完整而對寫程序Y保持改變的頁面的版本。而且注意，這是使用的術(shù)語“版本”，“已成版本(versioned)”，“正作成版本(versioning)”等是指時間瞬間的點(并且不應(yīng)與源代碼控制系統(tǒng)中永久性的版本混淆)。此外注意，事務(wù)處理的讀程序能與非事務(wù)處理的寫程序依次排序以便于實現(xiàn)。另外，非事務(wù)處理的寫程序可僅為了隔離的目的包括在“系統(tǒng)擁有”的事務(wù)中。因此提供可預(yù)測的事務(wù)處理的讀語義，因而事務(wù)處理的讀程序在給定的時間點可以依賴文件的“靜止”圖像。
回到圖5，一旦事務(wù)處理的寫程序提交文件V1，事務(wù)處理的寫程序Z可以打開文件V2(從V1沒有改變)用于讀一寫訪問(Z/RW)，如圖9所示。寫程序Z能看到寫程序Y的提交的改變，并能作出進一步的改變(Z寫入)。但注意，此時讀程序X仍然看到在文件首次被X打開時X所看到的原始文件頁，而不是任何Y所提交的改變。僅當讀程序X關(guān)閉文件并隨后重新打開時，讀程序X才可能看到寫程序Y的改變。如圖5所示，讀程序X也能看到寫程序Z所提交的改變，只要讀程序X關(guān)閉文件V2并在Z提交以后再打開它。換言之，如果讀程序X關(guān)閉文件并在Z提交以前重新打開它，讀程序X將看到版本V1，但是如果讀程序關(guān)閉文件并在Z提交后重新打開它，讀程序?qū)⒖吹轿募姹綱2。注意，如下所述，在文件打開時刻保持并打開比最新提交的版本更老的版本也是可行的。
應(yīng)該注意，這些語義是不能使用任何現(xiàn)有的文件共享模式表達的。這里描述的事務(wù)隔離語義隔離了各事務(wù)互相的影響，這與互相隔離句柄的文件共享模式成對比。現(xiàn)有的文件共享模式不變，并可用于附加的順序化。例如，在為由規(guī)定“拒絕寫”文件共享模式的同一事務(wù)的兩個不同線程為事務(wù)處理更新而打開文件的情況中，第二次打開將以破壞共享為由而拒絕。這就允許分布式應(yīng)用程序分配事務(wù)的工作負荷到多個線程、過程或機器，而同時保護由該事務(wù)作出的改變不受其他事務(wù)或非事務(wù)處理的工作程序的破壞。此外，這些語義保證可預(yù)測的已成版本的讀，其中每個讀程序能依賴文件的內(nèi)容在保持打開時仍然穩(wěn)定。
在下面列出的兼容性矩陣中，“是”意味著相對于附加的事務(wù)處理的限制是兼容的


因此，更新事務(wù)查看包括其改變的文件的最新版本，而經(jīng)事務(wù)處理的讀得到文件的提交的版本。一個另選方法(上面一般描述的方法)是在打開時提供文件最近提交的版本，而同時它是為事務(wù)處理讀打開，當作出更多改變并提交時，不允許版本改變。其好處在于讀程序在打開期間看到事務(wù)處理一致的數(shù)據(jù)樣式。
在第二個另選方法中，由讀程序看到的版本可以是第一次文件系統(tǒng)訪問時的版本或某個更早時間(即在TxF日志中更早點)的版本。，這可提供在此讀程序開始時最新提交的版本。此開始時間可以是該事務(wù)首次訪問該系統(tǒng)中任何NTFS對象的時間，或者這時間可以使用在一個集成的情況中其他的API(如使用日志序列號，或LSN)來定義。這種特性的優(yōu)點在于事務(wù)在多個文件中得到時間點的瞬態(tài)圖(point-in-timesnapshot)，當存在多個文件依賴性和鏈接時(如HTML或XML文件)是有用的。注意在此另選方法中，在同一事務(wù)中文件的多次打開可得到在該事務(wù)中第一次打開時所選的版本。但是可以認識到，需要由系統(tǒng)保存的版本歷史的數(shù)量在第二個另選方法中增加了。
術(shù)語“版本窗口(version window)”描述時間周期，在其中以前提交的版本的組被保持以支持選擇的版本方案。對上述的第一另選方法，版本窗口隨每個文件而變化，且是至今活動的文件的最早打開時間與當前時間之間的時間。對第二種方案，該窗含義為在系統(tǒng)中最早事務(wù)的開始LSN到當前時間的時間。可以支持這些方案的一種或兩種方案，而且由TxF 70所做的維持版本的工作基本上相同。為簡單起見，本發(fā)明在這里主要對于第一方案進行討論，其中由讀程序查看的版本是在該事務(wù)中第一次打開時刻的最新提交的文件版本。因此，在此第一方案中，因為流版本在打開時刻確定，應(yīng)用程序如果需要最新提交的數(shù)據(jù)，就必須關(guān)閉并重新打開句柄。這類似于在萬維網(wǎng)服務(wù)器中特別有關(guān)的情況(其中網(wǎng)站能事務(wù)處理地在線更新)，因此讀程序為了看到新提交的狀態(tài)需要關(guān)閉并重新打開句柄。
在一種實現(xiàn)中，寫入一個文件是到實際文件，因為假定改變最終是由寫程序提交的。如下所述，如果未能提交，通過在日志中得到的撤消信息，取消任何改變。因此，為提供版本隔離，每個針對一頁的寫首先導(dǎo)致為事務(wù)處理的讀程序保存老的頁。但注意，反過來做也是可行的，即保留原始文件完整直到改變被提交，從而寫程序(而非讀程序)將具有建立的新頁面。
在使用微軟Windows2000(或NT)操作系統(tǒng)的較佳實現(xiàn)中，從高速緩存管理器和虛擬存儲管理器或VMM的觀點呈現(xiàn)各自內(nèi)部存儲流，而不是在盤上為老版本建立各自文件。高速緩存管理器、VMM及它們與非事務(wù)處理的NTFS的關(guān)系在下列參考文獻中作詳細描述Helen Custer的“Inside WindowsNT”，Microsoft Press(1993)；Helen Custer的”Inside the Windows NTFileSystem”，Microsoft Press(1994)和David A.Solomon的“Inside WindowsNT，Second Edition”Microsoft Press(1998)，通過引入作為參考。
關(guān)于為事務(wù)處理讀程序保持版本，從虛擬存儲管理器和高速緩存管理器的角度來看，讀文件的較舊版本如同讀不同文件進行管理。這允許應(yīng)用程序簡單地將較舊版本映射到它們的地址空間，并使采用存儲描述符表(如重定向程序)訪問數(shù)據(jù)的客戶能透明地操作。注意，這之所以可能是因為在Windows2000操作系統(tǒng)中，VMM和高速緩存管理器參與文件系統(tǒng)的輸入/輸出(I/O)。文件系統(tǒng)(為非高速緩存訪問打開的文件除外)使用高速緩存管理器將數(shù)據(jù)映射到系統(tǒng)存儲器，而高速緩存管理器轉(zhuǎn)而使用VMM開始I/O。臟寫頁面的寫通常以延遲模式在后臺線程中發(fā)生。作為此結(jié)構(gòu)的結(jié)果，直接映射到應(yīng)用程序地址空間的文件與高速緩存管理器共享頁面，這樣，不管使用什么系統(tǒng)服務(wù)得到它，都能提供一致的數(shù)據(jù)樣式。注意，由此，網(wǎng)絡(luò)重定向程序(下面描述)對數(shù)據(jù)進行本地高速緩存，并在服務(wù)器處得到與其他客戶一致的數(shù)據(jù)。
為實現(xiàn)隔離，保持從仍然能讀到的最早提交的版本開始到經(jīng)更新的最新版本的多個版本。每個版本具有與追蹤有關(guān)最新版本變化的版本相關(guān)的數(shù)據(jù)結(jié)構(gòu)。如果讀出沒有改變的頁，該頁從文件中讀出(它可以在高速緩存中或?qū)懭氡P中)，而如果被改變的頁讀出，它從已改變的頁數(shù)據(jù)中讀出(它也可以在高速緩存中)。注意，某些版本可以沒有任何讀它們的事務(wù)，但可以保持它們的存儲器內(nèi)部結(jié)構(gòu)，因為它們在版本窗中，且將來可以得到打開請求。那些從未打開的版本不占據(jù)任何存儲器來儲存數(shù)據(jù)頁面。最新版本對應(yīng)于基文件流，且可以更新。
如圖6所示，每個版本用TxF“版本流控制塊”(TxFVSCB)描述。對一個文件的版本流控制塊以時間順序鏈接到一個表中，且除最新版本外的其他版本被提交/中斷，且是只讀的。最新版本可以提交或不提交。
每個TxFVSCB(如94)包括一個版本日志序列號96(版本LSN)，它在記錄到TxF日志中時，儲存事務(wù)的提交LSN。在一個實現(xiàn)中，對(最新的)未提交的版本，此LSN是TxF定義的“MAX_LSN”，以便于尋找小于當前時間點的最高LSN。希望讀早與此版本的提交的數(shù)據(jù)的讀程序能借助使用在改變表中的項(如981)訪問它，該表是存儲器內(nèi)部表98，它記錄了由TxFVSCB指向的版本改變的頁號。如TxFVSCB 94之類的每個TxFSCB還包括對應(yīng)于此版本的段對象指針(SOP)結(jié)構(gòu)100，它由高速緩存管理器和虛擬存儲管理器使用，并表示存儲器內(nèi)部流。還提供狀態(tài)標志102，其中之一表示該版本是否被提交。注意，只有最新的版本可以是未提交的。還包括VersionLength104數(shù)據(jù)字段，以及Change Table Pointer field(改變表指針字段)106，它包括指向記錄由版本改變的頁號的改變表98的指針。
如圖6所示，在改變表中(如981)，可以儲存與頁號相關(guān)的盤地址，以便于盤上找到該頁的以前版本，只要該頁在此版本中至少被寫一次。注意，如圖6所示，主要為了節(jié)省存儲器，頁的范圍能存在一個項中，該范圍處頁面連續(xù)存在盤上。圖7示出文件的多個版本的改變表940-943?？墒褂萌鐦溥@種有效的搜索結(jié)構(gòu)組織此改變表。
如果在事務(wù)中文件被打開用于只讀訪問，挑選出適當?shù)奶峤坏陌姹?，版本號由“readLSN”識別。如上所述，readLSN或者是當前的LSN，或者是較早的LSN，取決于使用什么類型的版本。選擇的版本是readLSN以前的最近提交的版本。如果版本不存在，如此版本太老，則打開失敗。如果該文件沒有任何與其相關(guān)的TxFSCB，用空的改變表建立新的TxFVSCB，并標記為未提交。使用默認的存儲器內(nèi)部流，使得現(xiàn)有的高速緩存的數(shù)據(jù)能用于讀。對寫訪問，如果最近的版本是未提交，它作為已提交被使用，否則如果沒有標記為未提交，建立新的VSCB，并標記為未提交。
當寫入一文件時為便于隔離，每當一頁數(shù)據(jù)(如在用戶級緩沖器108)被事務(wù)改變時，該頁基本上在原位(即在高速緩存110中)編輯(見圖8)。然后在適當時間，高速緩存110被高速緩存管理器和/或VMM 112寫到盤上(或其他合適的非易失性存儲媒體)114。通常如上所述，數(shù)據(jù)能通過將文件映射到存儲器或使用寫API來改變。當使用寫API時，通常使用高速緩存管理器112將改變復(fù)制到存儲器駐留頁116。注意，使用高速緩存管理器112將文件映射到系統(tǒng)存儲器。當使用存儲器映射時，由應(yīng)用應(yīng)用程序直接對與高速緩存管理器112映射頁相同的系統(tǒng)存儲器頁(如頁116)作出改變。改變經(jīng)“臟”位記錄下來，它指出在存儲器映射I/O的情況，改變駐留在過程專用頁表項(PTE)118中。通常，當存儲管理器對來自過程的工作集的頁面進行修整時，這些位就傳播到共享的(頁面幀號)PFN結(jié)構(gòu)120。它們也能由應(yīng)用程序60使用系統(tǒng)API直接傳播，以刷新映射段。注意，臟頁也能周期地寫出。
為了保證存儲器映射的改變包括在事務(wù)中，在提交時刻系統(tǒng)將刷新每個應(yīng)用映射段的虛擬地址范圍。從映射它們的應(yīng)用程序的范圍中起動此刷新。事務(wù)處理的語義可以這樣定義只有直接由應(yīng)用程序刷新的頁才能包括在該事務(wù)中(如刷新是事務(wù)性地作出，而不是對用戶段中的字節(jié)的單獨修改)。另外，這可以通過附著(KeAttachProcess)到具有映射段并做此刷新的過程的系統(tǒng)線程來實現(xiàn)。段的列表保持在相應(yīng)的事務(wù)表項中。注意，由文件API作出的改變在提交時也需要刷新到盤中。這是因為在頁面寫蝕刻，不可能在從以前事務(wù)留下的臟頁面寫和在當前的事務(wù)中由存儲器映射作出的改變之間進行區(qū)分。
因此TxF同時支持由事務(wù)作出的只讀和讀/寫的文件打開。當事務(wù)以只讀訪問方式打開文件，而該文件目前未被任何其他事務(wù)打開時，該文件上的語義與以非事務(wù)方式打開的相同。如果事務(wù)打開一文件用于讀/寫，則TxF需要的一種該文件的結(jié)構(gòu)，每個流一個，以及對流版本的一種結(jié)構(gòu)，以存儲其每個事務(wù)的范圍，如圖9所示。用于此打開的數(shù)據(jù)結(jié)構(gòu)如圖9所示，其中“文件對象”是由用戶的文件句柄映射的對象，“FCB”是NTFS文件控制塊，“SCB”是用于打開的特定流的NTFS流控制塊，“NP SCB”是主要用于保持對文件映射的段對象指針的非頁面流控制塊，而“CCB”是每個文件對象范圍結(jié)構(gòu)。注意在TxFFO中的標志指出該文件何時由事務(wù)打開用于讀。
在圖9中，TxFCB結(jié)構(gòu)是用于由TxF保持的每個文件的改變的撤消數(shù)據(jù)的一個錨標，而且還包括對該事務(wù)的參照。TxFSCB是用于流版本的錨標，TxFVSCB是用于流的特定版本的撤消數(shù)據(jù)的錨標。TxFO結(jié)構(gòu)描述對流的版本的特定事務(wù)訪問，且它捕捉指向該版本的有關(guān)共享TxF結(jié)構(gòu)的指針。
如圖10所示，如果第二事務(wù)t3在以前的只讀事務(wù)做完以前打開文件用于讀/寫，則該文件的老版本基本上移位(到圖10中的右側(cè))，為表示新版本的結(jié)構(gòu)留出空間。因此，圖10表示由修改文件當前版本的事務(wù)t3作出的讀/寫打開，由訪問該文件最近提交的版本的事務(wù)t2作出的只讀打開，以及由訪問更早提交的版本的事務(wù)t1作出的另一個只讀打開。注意，為簡單起見，每個FileObject指向同一個SCB，而NTFS不知道文件的版本。而且，每個FileObject在唯一的非分頁SCB中擁有其自己的段對象指針組。注意，通常并不使用用于只讀事務(wù)的段對象指針，除非用戶實際上映射該流。從對未加修改的頁面的當前流以及從對已修改頁的記錄文件維護高速緩存訪問。對每個文件對象的TxFO有效地捕捉該事務(wù)訪問文件的哪個版本。
通常，因為TxF事務(wù)具有無關(guān)于NTFS句柄的生命周期，因此，TxF結(jié)構(gòu)具有無關(guān)于NTFS句柄的生命周期。當兩者都出現(xiàn)時，如圖9-10所示，它們鏈接在一起，其中使用意義明確的接口在兩邊建立單向鏈結(jié)。例如，當發(fā)生對一個文件的事務(wù)處理訪問時，校驗到TxFCB的FCB鏈接。如果是空，它使用TxF例行程序建立。但是如果TxF已經(jīng)存在，使用File-Id由TxF從TxF文件表中對其進行查找，否則分配一個新的。類似地，當FCB被重新分配且TxFCB鏈接是非空，則調(diào)用TxF例行程序用于單向(NTFS到TxF)鏈接的刪除。
當沒有事務(wù)處理的讀程序使文件打開或能在將來打開文件的這個版本時，對文件重新分配TxF結(jié)構(gòu)。即使NTFS目錄由于目錄本身的刪除(在遞歸刪除方式中發(fā)生)可以去掉，但只要在TxFSCB結(jié)構(gòu)中存在名字空間隔離信息，就能維護目錄。TxF結(jié)構(gòu)的生命周期通過參照計數(shù)來管理。
記錄服務(wù)按本發(fā)明的另一方面并如下所述，對于永久性狀態(tài)的記錄與恢復(fù)，TxF 70使用記錄服務(wù)74(圖2)，它允許多級記錄而不是只依賴于普通的NTFS記錄，以支持長期運行的事務(wù)。下面將明白，這提供了許多好處。例如，典型的NTFS記錄大小在約4兆字節(jié)，對于目前的短期元數(shù)據(jù)記錄，這個大小很適合，但是典型的用戶定義事務(wù)將很快超過這樣的記錄。而且，相對于記錄的TxF事務(wù)操作數(shù)目，很可能有大量記錄的NTFS操作。此外，NTFS元數(shù)據(jù)提交操作鎖定目錄，而占用長時間的TxF事務(wù)將對文件系統(tǒng)的性能有不利的影響(在假定的單級記錄方案中)。
傳統(tǒng)的NTFS記錄已有文檔很好描述，因此在這里除簡單概要以外不作詳述，敘述的范圍是結(jié)合本發(fā)明的事務(wù)處理文件系統(tǒng)對其的使用。在NFTS作出改變以前，通過寫入對操作的撤消和/或重做記錄到NTFS中，NTFS提供文件系統(tǒng)操作的中斷/失敗恢復(fù)功能。NTFS記錄是每卷的文件，用于記錄影響該NTFS卷的操作，包括改變NTFS數(shù)據(jù)結(jié)構(gòu)的操作，如建立文件命令、改名等。注意，記錄的是元數(shù)據(jù)，而不是用戶文件數(shù)據(jù)，如被寫入的字節(jié)。該日志作為文件保持，并被訪問以便從系統(tǒng)失敗中恢復(fù)，即如果系統(tǒng)崩潰，將使用已知的技術(shù)，可以撤消或重做部分完成的操作。NTFS不提供持久性，即NTFS不強制其日志提交。
按本發(fā)明的一個方面，在多級恢復(fù)機制中，TxF事務(wù)和恢復(fù)管理分層在NTFS的頂部。如上所述，TxF將NTFS操作作為建立用戶級事務(wù)的低級部件處理。為了恢復(fù)，TxF保持更高級日志，并且在檢測到TxF強迫其自己的TxF日志在“數(shù)據(jù)”之前，將記錄的NTFS操作處理作為關(guān)于更高級日志的“數(shù)據(jù)”進行處理。在此情況下的“數(shù)據(jù)”是NTFS日志，一個可恢復(fù)的存儲本身。
如圖11所示，為了完成多級記錄，通過以利用已經(jīng)可用的NTFS 64的可恢復(fù)性的方式協(xié)調(diào)每個日志的LSN(這里稱為TxFLSN和NTFSLSN)強制高級TxF日志124在低級NTFS日志126之前完成。如下所述，對于不由NTFS事務(wù)管理的數(shù)據(jù)(即流字節(jié)本身)，TxF 70實質(zhì)上完全地管理可恢復(fù)性。
為保證較高級TxF日志124強制在其“數(shù)據(jù)”(即在NTFS日志126中的記錄)之前(而沒有無效地強制TxF日志在每次NTFS操作之前)，提供TxF回撥，使得每當NTFS 64將要強制在其日志126中的數(shù)據(jù)時，NTFS 64就調(diào)用它。在此調(diào)用中，NTFS 64指出需要刷新的最高NTFS LSN。同時，TxF 70保持TxF使用的最近的NTFS事務(wù)的映射128，以便將NTFS提交LSN映射到對應(yīng)的TxF LSN。注意，設(shè)計了名字空間修改操作，使得TxFN知道TFS提交LSN。NTFS日志并不持久，因為它相對不頻繁地刷新到盤中。因此，在日志高速緩存中存在合理數(shù)量的TxF記錄，它們在單個I/O操作中一起刷新到盤中。
響應(yīng)此回撥，TxF 70強制TxF日志124直到對應(yīng)于在NTFS日志中被強制的最高NTFS Commit-LSN的TxF記錄。但是應(yīng)該注意，刷新TxF日志124到最高記錄僅是更加優(yōu)化，因此保證較高級日志首先刷新的其他方法(如當NTFS要刷新其日志時刷新所有新的TxF記錄)也滿足需要。在恢復(fù)期間，在TxF開始其恢復(fù)以前NTFS完成其的恢復(fù)。
雖然這保證TxF日志124在NTFS日志126之前刷新，但某些靠近TxF日志結(jié)束的日志記錄可能已完成未被NTFS提交的NTFS操作，這種記錄與已被提交的記錄混合。重要的是將其對應(yīng)的NTFS操作已被提交的TxF日志記錄與未被提交的那些加以區(qū)別，因為這決定了在恢復(fù)期間是否應(yīng)用TxF日志記錄。
也將明白，這是重要的，因為在重做期間重復(fù)一個操作，或撤消從未發(fā)生過的操作是不正確的。作為一個例子，考慮下面在TxF日志中可能記錄的情況

在上述情況中，不可能知道是否正確地反轉(zhuǎn)(撤消)了改名操作。每次簡單地做此反轉(zhuǎn)操作是不正確的。因為如果在NTFS中改名實際上從未發(fā)生過，Y將改名為X，取代它。因此，在試圖打開系統(tǒng)鏈接時可能失敗，因為該鏈接由于未發(fā)生NTFS操作而不存在。文件X將被丟失，而Y改名為X，但是，如果TxF 70能夠查明改名是否發(fā)生，就能精確判定是否要應(yīng)用撤消操作。
為在請求一個操作前判定操作是否實際發(fā)生，即是否被NTFS 64提交，TxF將相應(yīng)記錄寫到其日志124。然后TxF接收TxF LSN，后者為NTFS 66提供對給定文件的請求的操作。雖然在提交后讓NTFS 66將TxF LSN放到其對應(yīng)的NTFS日志記錄(或多個記錄)中是可行的，但這是低效的。取代的是當NTFS提交操作時，作為提交的一部分，NTFS將TxF LSN寫到在NTFS卷上保持用于該文件的記錄中。在NTFS中，對卷上每個文件(及目錄)已經(jīng)以稱為主文件表的結(jié)構(gòu)保持了記錄。因此，如在圖11所示，TxF LSN寫到在對此文件(如文件3)的記錄中的一個字段(如1323)中。注意，也可使用另外的數(shù)據(jù)結(jié)構(gòu)，只要每文件的記錄已經(jīng)在每個NTFS卷上可以得到。
隨后，系統(tǒng)崩潰之后，在恢復(fù)期間，在TxF使NTFS完全實現(xiàn)其恢復(fù)之后，TxF首先檢查以確定在系統(tǒng)崩潰前在TxF日志中記錄的操作是否在盤上進行(通過NtfsTxFGetTxFLSN(file-id，*TxFLsn)調(diào)用來調(diào)用NTFS)。如果對文件的NTFS操作提交并在系統(tǒng)崩潰前保存到盤中，TxF日志124中記錄的TxF LSN就小于或等于在文件記錄字段中的TxF LSN，因為NTFS恢復(fù)保證文件記錄將被恢復(fù)。如果在文件記錄的TxF LSN小于TxF日志記錄的LSN(或不是在該文件的文件記錄中)，則可以知道NTFS操作未被提交，而且對應(yīng)的TxF日志記錄不能用于撤消。
但注意，為保證正確的恢復(fù)，如果一個對象在恢復(fù)窗期間被刪除，TxF將推遲該文件記錄的刪除(因而保留文件標識符file-id)，直到所刪除日志記錄在日志中被遺忘之后為止。這是借助建立到該文件的系統(tǒng)鏈接完成的。此外，如果建立一個新文件，在NTFS確定將用于建立的文件標識符之前不寫入TxF日志記錄。這就實際上將文件標識符記錄入TxF日志。注意，對非事務(wù)處理的建立也如此，NTFS將當前的TxF LSN寫入文件記錄，然后處理這種情況，其中在恢復(fù)窗期間重新使用文件標識符(包括序號)，并在建立之前使TxF跳過日志記錄。
因此，如果NtfsTxFGetTxFLSN調(diào)用發(fā)現(xiàn)，在恢復(fù)時刻文件標識符不存在，則或者在事務(wù)提交之后且在系統(tǒng)崩潰之前文件被非事務(wù)處理地刪除，或者在建立操作之后立即發(fā)生系統(tǒng)崩潰。注意，在第一種情況，沒有涉及TxF且在恢復(fù)窗期間文件記錄被刪除。在第二種情況，TxF建立的日志記錄送到TxF日志盤中，但NTFS對它的提交未持續(xù)。只有當處理一個建立日志記錄時第二種情才能檢測到。
因為撤消記錄用于中斷未完成的事務(wù)，如由NtfsTxFGetTxFLSN看到的文件標識符不存在的記錄可以簡單地忽略。
應(yīng)該注意，在中斷、崩潰恢復(fù)和向前恢復(fù)期間，由日志驅(qū)動的重做和撤消動作在NTFS過濾一驅(qū)動程序模型中的過濾驅(qū)動程序堆棧的頂部起動，允許任何中間的過濾驅(qū)動程序看到這些動作。對應(yīng)于重做和撤消動作的IRP被專門標記，使得過濾驅(qū)動程序能選擇忽略它們。這些IRP將包括通常的事務(wù)狀態(tài)而文件對象一般將指向事務(wù)對象。但是，因為事務(wù)處于特定狀態(tài)，TxF將知道它們需要專門處理。例如，TxF不試圖將這些動作包括在一個事務(wù)中，或?qū)⑺鼈冏鳛榉鞘聞?wù)處理。
除了記錄名字空間操作以外，TxF部件70與記錄服務(wù)74協(xié)同工作以記錄在其他操作中的頁改變。如上所述，在中斷情況為維持版本也為了支持撤消操作，在通過API對存儲器中的頁面實際作出改變以前，相應(yīng)的撤消記錄寫到(非強制性的)TxF日志126。如圖12所示，然后寫整個頁面(通常寫到存儲器內(nèi)和如下所述稱為TOPS流134的盤上的頁流)，它允許已成版本的讀程序在單個I/O操作中讀出該頁面。在日志寫以后，對該文件的改變表98用日志序號(TxF LSN和在TOPS流134中的偏移量)標記，此改變隨后應(yīng)用到該頁。
對由頁I/O改變的頁，如從已被用戶映射段修改的頁和/或由較早對正在寫入的API的調(diào)用修改的頁所得到的頁，完成頁面的寫。此分頁的寫能在后臺的線程中，或可以是在提交時刻刷新部分。在任何情況，TxF 70首先檢查改變表98(圖6)，以查看該撤消是否在TxF日志126中已被抓住。若是，系統(tǒng)強制TxF日志126直到表98中標記的TxF LSN，在大多數(shù)情況它將返回而沒有I/O。如果改變表98未被標記，得到該頁的撤消版本并寫到TOPS流134和TxF日志126。多頁I/O是常見的，因為后臺線程試圖以文件偏移量的次序?qū)㈨撁娼M合在一起。在這些情況，多個撤消被寫入單個、大的I/O。在這些情況的撤消也將在單個、大的I/O中讀出。
在準備的記錄被強制到TxF日志126以后，撤消映象在TxF日志126和TOPS流134中的盤上，而修改的文件頁在文件中它們的位置處。因此，提交是將提交記錄寫入日志126的簡單操作。中斷的實現(xiàn)是通過以逆序執(zhí)行撤消記錄，并將它們應(yīng)用到基文件，隨后刷新文件，隨后強制寫中斷記錄。如果中斷記錄存在于日志126之中；在恢復(fù)時刻就忽略這些撤消記錄。注意，通過在不頻繁的操作(中斷)期間刷新文件，大的(頁面大小)補償日志記錄(CLR)不需要作為重做記錄寫入，這顯著地保存了空間。
獲得一個撤消映象與得到以前提交的頁版本是一樣的，即文件的撤消映象首先在文件的以前版本中搜索。如果映象留在存儲器中，撤消映象從存儲器中取出。否則，映象由非高速緩存的I/O操作從盤中讀出，因為臟位被非公開地處理且并不需要知道，就無法確定當前留在存儲器的映象是否是臟的。
如上所述，每當一頁面由使文件打開以寫入的事務(wù)改變時，該頁面就在原位(即高速緩存器中)編輯。隨后，高速緩存在不同時刻被寫入盤中(圖8)。但是在頁面數(shù)據(jù)被改變時，老的頁面數(shù)據(jù)需要保存，所以如果事務(wù)中斷或系統(tǒng)失敗，老的頁面數(shù)據(jù)能夠恢復(fù)。為此，老的頁面被復(fù)制到TOPS流134，而改變記錄在TxF日志126中。如圖12所示，日志記錄(如X2)包括到此頁面的偏移量，而日志126不需要保持數(shù)據(jù)，而只需對應(yīng)其的記錄。因此，為使頁面恢復(fù)，TxF使用隨時間順序記錄改變的改變?nèi)罩?。注意，對于正在做版本，為有效起見使用在改變?8中到TOPS流134的偏移，而不是訪問TxF日志126。但是在系統(tǒng)失敗的情況，存儲器內(nèi)結(jié)構(gòu)的版本流控制塊在恢復(fù)時刻不存在。而且單獨在存儲器內(nèi)的任何文件版本是不可恢復(fù)的。因此為了恢復(fù)，可以將日志中的記錄用于在失敗期間中斷事務(wù)，并用于持久地完成在系統(tǒng)失敗前提交的事務(wù)。日志項(或日志記錄)的順序特性保存了改變的次序。
在本發(fā)明中，由于其性能和其他原因，頁面寫的日志記錄分離成兩部分。與主日志內(nèi)聯(lián)(inline)的部分保存其相對于其他日志的次序，而另一部分包括(相對更大量的)字節(jié)，它們提供操作的細節(jié)，即改變的頁面數(shù)據(jù)。因此，按本發(fā)明的一個方面，如在圖12所示，每當頁面由事務(wù)改變，老的頁面數(shù)據(jù)復(fù)制到(連續(xù)的)TOPS流134，并在TxF日志126記錄改變。如上所述，在調(diào)整表以將事務(wù)處理的讀程序映射到復(fù)制頁面以后，該頁面隨后可以改變。如圖12所示，日志記錄(如X2)包括到在復(fù)制頁的流中的此頁的偏移，因而主日志不需要保持數(shù)據(jù)，只保持具有對應(yīng)其的偏移的記錄。
但是，出于性能原因，這些日志被不同地刷新到盤中。因此，頁面和日志126在給定時刻可能都不能持久，例如系統(tǒng)可以在日志126被刷新到盤和/或頁面被刷新到盤上之前失敗。保證頁面數(shù)據(jù)不丟失的簡單方法是在兩者之間強加排序，即在刷新日志記錄到盤上之前總是先將頁面刷新到盤上。因此當恢復(fù)過程中使用日志時，如果日志記錄存在，對應(yīng)于該記錄的正確的頁版本也已知繼續(xù)保持，但是發(fā)現(xiàn)此次序依賴關(guān)系很大地降低了系統(tǒng)的性能，因為日志刷新操作根據(jù)許多無關(guān)的因素在不同的日志上更加有效操作。例如為了改善性能，頁面通常以多組形式被刷新，如使用惰性寫算法一次16頁，而日志在滿時，或在后臺處理的不同時刻被刷新。
按本發(fā)明的另外方面，提供一個系統(tǒng)和方法，它們使頁面和日志能以相對彼此任意的次序刷新到永久存儲器中，而且以這種的方式，確保在失敗的情況能恢復(fù)正確的頁面。這是通過將信息加到日志126和頁面數(shù)據(jù)中來實現(xiàn)，將兩段信息以一致狀態(tài)(例如及時)有效互相鏈接。更具體地說，保持一個循環(huán)計數(shù)136(如以字節(jié)，雖然可選擇使用一個字或更大容量)，表示頁面的當前狀態(tài)，如每當指向TOPS流134的指針翻滾回到起點時循環(huán)計數(shù)就加1，而且該循環(huán)計數(shù)與日志記錄同步。
如圖12所示按本發(fā)明的一個方面，同步是通過將循環(huán)計數(shù)值保持在與復(fù)制到TOPS流134頁面相關(guān)的日志記錄來實現(xiàn)的。這在圖12中用標號為138的方框表示，它提供某些記錄的數(shù)據(jù)字段的擴展表示。還示出。在每段中的最后部分(如字節(jié))復(fù)制到日志記錄以便在那里保存。注意，一個頁面包括8個512字節(jié)的段，每個段如這里所描述，但可以理解，其他頁和/或段的大小是可能的。而且在流數(shù)據(jù)中每段的最后部分用循環(huán)計數(shù)代替，如在圖12中用標號為140的方框表示，用在每段的最后部分中代替的循環(huán)計數(shù)提供頁數(shù)據(jù)的擴展表示。如在圖12所示，如果頁和日志均被刷新，在每段的未端的循環(huán)計數(shù)值將匹配在記錄中的循環(huán)計數(shù)值，即兩者具有匹配的特征。
如果只有頁面數(shù)據(jù)(外部部分)被寫入盤，系統(tǒng)將找不到內(nèi)聯(lián)(日志)記錄，因此找不到該頁面，沒有什么可恢復(fù)。該狀態(tài)就認為是一致的。
但如果記錄出現(xiàn)在日志中，在系統(tǒng)崩潰前，頁面可以被或可以不被刷新。圖13通常表示當在退回過程中記錄到達時，頁面及其日志是否均被刷新到盤中。首先在步驟1300，記錄被訪問，以通過其儲存到流134的偏移量找到頁面。然后，在步驟1302讀出頁面并從中取出每段的最后部分，在步驟1304將其與存在日志記錄中的循環(huán)計數(shù)比較。如果只有內(nèi)聯(lián)(日志)記錄被寫入盤，系統(tǒng)崩潰以后存在外部部分(頁面數(shù)據(jù))的每個段中的唯一的記號(每個循環(huán)計數(shù))將不匹配存在于內(nèi)聯(lián)記錄數(shù)據(jù)的循環(huán)計數(shù)。在此情況中，如步驟1306所示，系統(tǒng)得出結(jié)論，因為老的頁面未寫入盤，而新頁面也未寫(只有在兩個日志被刷新時它才被刷新)。因此該頁面已知處于以前的老狀態(tài)。
相反，如果在步驟1304中，日志中的循環(huán)計數(shù)匹配對應(yīng)頁的每段的最后部分中的循環(huán)計數(shù)，日志和頁面就已知均被成功地刷新。因此，就知道被復(fù)制的頁面保持，而存在日志記錄中每段的最后部分在步驟1308恢復(fù)到復(fù)制的頁。
此時，被復(fù)制的頁面可由讀程序訪問，并提供適當?shù)陌姹?。任何對當前頁面作出的記錄改變可用?步驟1310)使新的讀程序和/或?qū)懗绦蚩吹?。在該情況，知道老的數(shù)據(jù)被正確地捕獲，并必須作為中斷的一部分恢復(fù)到文件頁。注意，盡管中斷，現(xiàn)有的事務(wù)處理的讀程序?qū)⒗^續(xù)從TOPS流134讀到老的數(shù)據(jù)。
應(yīng)該注意，使用在每段的結(jié)尾的唯一的記號還進一步檢測分裂(部分)寫，其中某些頁面被復(fù)制，但不是所有頁面。注意，盤硬件保證段將寫滿，但不保證一頁數(shù)據(jù)(如8段)將作為一個單元被寫。在這種情況，循環(huán)計數(shù)是“n”和(推測的)“n-1”值的某種混合，該記號將不匹配記錄的記號信息。就如同整頁沒有保存來處理這種情況。
注意，當循環(huán)計數(shù)本身重算，有可能使其匹配構(gòu)成現(xiàn)有頁面上的記號的計數(shù)(如它已經(jīng)在存儲器內(nèi)相當長時間)，因此使部分的寫入不能被檢測。例如，如果使用重算的循環(huán)計數(shù)，且如果它匹配存儲在頁面上的現(xiàn)有循環(huán)計數(shù)，則不管是所有頁面還是某些頁面被復(fù)制，記號是一樣的。可以理解，在此情況的記號校核將指出，整個頁面數(shù)據(jù)的保持，雖然事實不是。
此問題能以許多方法解決。一個解決方法是在每次循環(huán)退回事件之后讀頁面一次，以驗證是否存在不匹配。如果匹配，可以調(diào)節(jié)二個循環(huán)計數(shù)之一以避免匹配。為保證每次循環(huán)退回(即每次循環(huán)計數(shù)回到0)只發(fā)生一次上述情況，可使用單獨的驗證位映象141保持每頁的“驗證”狀態(tài)，即每位是退回之后的一個狀態(tài)，且當頁面首次檢查循環(huán)計數(shù)匹配時作切換。注意，使用自由空間位圖跟蹤一頁是否為空閑或使用，且為有效起見，上述解決方案將附加的位圖加到跟蹤驗證狀態(tài)。
另選的解決辦法(對上述讀和比較操作)再次跟蹤驗證狀態(tài)，但是當“驗證”狀態(tài)是在頁面使用時設(shè)置，如上所述循環(huán)計數(shù)被寫到頁面中，且強制寫入。如果寫入成功，則寫入不是部分進行。對大的TOPS流，由于較少的輸入/輸出I/O操作，此另選方法調(diào)節(jié)得很好，因為循環(huán)計數(shù)匹配頁面的情況可能相對很少出現(xiàn)。
又一種另選的方法是結(jié)合檢查頁面駐留的首次兩種方法的組合，即如果頁面駐留在高速存儲器中，因為不需要實際上的讀盤而實現(xiàn)第一種(讀)另選方法，否則執(zhí)行第二種(寫)另選方法。
延遲的重做另選方法上述恢復(fù)機制將文件的臟頁在提交時刻寫入盤，防止在多個事務(wù)上成批頁寫入。為達到在多個事務(wù)上成批頁寫入，可提供一個另選的“延遲重做”方案，它在恢復(fù)的方面上做了相反工作。此方案將重做記錄寫入日志，并當沒有讀程序仍在讀它時，將老的提交處理施加給基文件。為了支持老的提交的版本的讀，不在原位做出改變，而是當現(xiàn)有的頁的原位版本不再需要時，只能原位應(yīng)用到該文件。
延遲重做方案共享由原位更新方案使用的許多原則，例如，它以與版本控制塊和多個存儲器內(nèi)流十分類似的方法支持做版本。但是，改變表保持重做頁面的LSN，而不是撤消的LSN。通常如圖14所示，最早的盤上的版本總是基文件，而較新的版本在其上建立增加的改變。當讀程序離開時，較早的版本合并在基文件中。為了利用此方案主要優(yōu)點，多個版本能同時合并到基文件中，因此獲得I/O效率。同時合并多個版本的另一優(yōu)點是在大的讀操作中日志能被有效地讀出。
但是，日志可以用頁面充填，它們返回存儲器用于(可能許多)活動的文件，實質(zhì)將順序的日志調(diào)整到既作為恢復(fù)日志也是隨機頁面的文件中，這可能成為系統(tǒng)中的瓶頸。
類似于原位更新方案，最新的版本是可更新的。存在一個版本控制塊(TxFVSCB)與每個版本相關(guān)，且每個TxFVSCB指向改變表，這是一個記錄由該版本改變的頁面號的存儲器內(nèi)的表。盤地址可以與每個頁號一起存入，以便找出在盤上的頁面，只要它至少寫入一次(重做映象)。缺少盤地址意味著該頁從未寫入盤中。為了節(jié)省存儲器，頁范圍可存入一個項中，在這個范圍內(nèi)頁面連續(xù)地存在盤上。
版本LSN是提交該版本的事務(wù)的提交記錄的LSN。對當前可更新的版本沒有這種LSN。SOP指針是指向?qū)?yīng)此版本的段對象指針結(jié)構(gòu)的指針。使用該指針，能找到該存儲器內(nèi)頁面。類似地提供版本長度。
版本控制塊以時間順序鏈接到表中。最早的版本是基流，而改變表不包含此版本的任何項。
在打開時刻，如在上述另選方案，給予版本之一一個文件句柄。最新版本的存儲器內(nèi)流部分由日志返回(不是由基文件全部返回)。這樣，對流的改變寫入日志。如果在版本窗的任何版本中該頁未改變，則從基文件完成讀，否則它們從日志中完成。
在讀的時候，查閱對應(yīng)于該版本的改變表，以判定在該版本中頁面是否被修改。若是，I/O對著日志中適當?shù)奈恢靡匀∪朐擁撁嫦收?。若不是，則查閱該頁下一先前版本；此過程一直持續(xù)到找到該頁的最新提交的復(fù)制。如果多個版本包括該頁的復(fù)制，用VMM調(diào)用檢查它們的存儲器駐留內(nèi)容。如果找到存儲器駐留頁，對其復(fù)制，否則使用最新版本的LSN從日志中將其讀出。注意，如果該頁是在駐留內(nèi)容被檢查和作出復(fù)制的時間之間從系統(tǒng)存儲器裁剪出，也沒有關(guān)系，因為產(chǎn)生遞歸的故障并且頁面在其后被復(fù)制。為了得到系統(tǒng)地址以復(fù)制這些頁面，使用高速緩存管理器映射它們到系統(tǒng)地址空間。
在圖14中示出四個版本V0-V3(但其他數(shù)目也可以)，其中用“X”標記的頁表示在版本中的改變。改變表1420-1423示出已寫入頁面的LSN。在最近(可更新的)版本中的某些頁還未被寫入。在此情況，考慮一個例子，其中FileObjectB訪問頁面50(50)。對文件版本V1的改變表1421表示此頁在該版本中未被改變。因此，通過對該頁檢查文件版本V0的駐留內(nèi)容并若是駐留的(不出故障)將其復(fù)制，借此處理故障。如果文件版本V0沒有頁是駐留的，則將它從盤讀出(在此情況，從基文件讀出)。
作為另一個例子，如果FileObjectB訪問頁面200(200)，且該頁在存儲器內(nèi)，訪問很簡單完成。但是如果不是，產(chǎn)生頁面故障，并通過從LSN 2500處的日志讀出它以達到讀的目的。
作為另一個例子，考慮FileObjectc訪問頁面100(100)。因為該頁面在版本V2沒有改變，檢查版本V1，且通過從存儲器映象(若是駐留的)或通過在LSN 2000讀出日志以滿足讀取。
對于文件寫，在頁調(diào)出的時刻，頁面以重做記錄的形式寫到日志中，重寫記錄也描述了流偏移和流名字。在此時，LSN被標記在對該版本的改變表的頁縫中。頁面寫由一個系統(tǒng)線程在后臺中發(fā)生，并通常以順序頁面次序?qū)懭?。在提交時刻，在那個版本中的臟頁面被寫入日志，隨后是一個提交記錄。如果在事務(wù)期間頁面被寫出多次，則完成了多個日志寫。這些寫進到日志的末端，且改變表項被改變成指向新的位置。如果新的寫事務(wù)在提交之后開始而沒有對讀事務(wù)有任何干涉，主存儲器流被新事務(wù)再使用。否則，就由讀程序?qū)ζ渖暾?，而寫程序事?wù)建立新的流來工作。注意，在延遲重做方案中，改變的頁面能寫到TOPS的流(就象原地更新方案)以得到有關(guān)的好處。
在系統(tǒng)崩潰后，恢復(fù)是相對直接的，因為提交事務(wù)的重做信息在日志中，并能簡單地加到主數(shù)據(jù)流。注意，版本控制塊是存儲器內(nèi)結(jié)構(gòu)，因而在恢復(fù)時刻不存在。
當老的讀程序結(jié)束它們的事務(wù)時，老版本不再需要保存。在此時，版本從最老的開始以每次一個版本的方式合并到主流中。因為版本被合并，就從版本的鏈接表把它們?nèi)コ?。通過將那個版本中的改變頁面(在改變表中查找的頁號)復(fù)制到基流并強制到盤中，以每次一頁方式發(fā)生合并。此復(fù)制操作讀出不是當前駐留的頁面的日志。若可能，執(zhí)行大量的I/O操作以從日志捕獲頁面范圍。如在圖14中，如果版本V0不再需要支持做版本，版本V1就合并到版本V0中。此合并能發(fā)生而不必鎖定版本V1，因為當合并進行時每個頁面的副本存在于版本V1和版本V0中，而對V1的改變表在整個過程中不變。
當合并完成以后，若版本V1不在版本窗中，V1的版本控制塊簡單地從版本表中除去。通常，合并將延遲直到從讀程序釋放多個版本。在本例中，V0、V1和V2在它們離開版本窗時能一起合并到基文件中。對多版本的合并，改變表首先以這種方式合并當在多個表中同樣的項被修改時，從最高版本號來的LSN先挑選出來。這實質(zhì)是在各事務(wù)之間將寫分批，這是此方案的一個優(yōu)點。在一個版本被合并以后，其日志記錄適當?shù)貜幕顒拥娜罩局腥コ?br> 通常，合并應(yīng)盡可能早做。每當寫程序離開時，版本窗前移。那時，某些版本標記為適合于合并。當標記了多個版本，一個工作項放在系統(tǒng)線程上以進行合并。
原地更新方案和延遲重做方案都執(zhí)行差不多相同數(shù)量的I/O。原地更新方案可以同步地讀撤消命令(因為有時可以在存儲器中找到它，例如如果并發(fā)的讀程序最近在讀它們)。原地更新方案將頁面寫出到基文件，并還將撤消順序地寫到日志中。相反，延遲重做方案需要將重做寫入大的隨機I/O，且需要隨機地讀日志以便合并一版本。此外，延遲讀方案需要將文件頁寫到盤上，雖然它使各版本上的寫最小。在存儲器中尋找這些日志頁面的機會因此是非常低，給出了合并可能延遲多長時間。
在何時何地完成I/O方面有性質(zhì)上的差別。在延遲重做方案中，最新的存儲器流由日志返回，而不是基文件。這很可能是最經(jīng)常使用的流，因為它處理更新工作，比較地加重日志的負擔。對于已成版本的讀程序，兩種方案使用日志作為分頁設(shè)備。
延遲重做方案與提交處理較少同步工作，因為大量的事務(wù)工作在后臺完成，但是對每次寫API或存儲器更新的寫程序沒有顯出更快，因為這些在高速緩存中完成。相反，在提交時刻的刷新是在提交的響應(yīng)性方面的差別顯示增加處。對較大的更新事務(wù)，后臺系統(tǒng)線程看來調(diào)度異步的寫，它有時減少響應(yīng)性的差別。類似地，原地更新方案也能通過在后臺中完成對文件API的撤消工作而減輕在提交時的負擔，但對在用戶映射段中作出的改變是不可行的。
原地更新方案比延遲重做方案簡單，因為原地更新方案不需要處理調(diào)度異步合并操作的問題。而且，原地更新方案不需要處理在前臺和后臺活動之間的速度不匹配問題，這有時可能阻礙日志空間并產(chǎn)生資源獲取問題。
最后，用延遲重做方案不必改變正常運行記錄算法，就可能存檔及向前退回，因為在日志中重做記錄是可得到的。但是，因為沒有撤消記錄，需要執(zhí)行對日志中的某些前向掃描，以便在對該事務(wù)應(yīng)用任何重做之前找出事務(wù)的提交狀態(tài)。
在網(wǎng)上的文件系統(tǒng)事務(wù)通常如圖15所示，通過內(nèi)部核心到核心的“重定向程序”協(xié)議(如SMB協(xié)議)來訪問遠程文件。此協(xié)議反映了在如文件服務(wù)器之類的遠程機器148上的客戶機146上執(zhí)行的文件系統(tǒng)操作。當然，其他協(xié)議和機制(如Wev DAV、NFS等)能得到等效的結(jié)果。所以，如非事務(wù)文件系統(tǒng)訪問那樣，遠程文件被識別，并且IRP指向在客戶機器146上的重定向程序文件系統(tǒng)驅(qū)動程序150。已經(jīng)知道，此驅(qū)動程序150與客戶機的高速緩存對接以讀和寫數(shù)據(jù)。如從針對遠程機器的文件系統(tǒng)154的應(yīng)用程序152來的文件系統(tǒng)請求(如訪問在遠程盤156上的文件G/Fname)之類的請求被重定向程序驅(qū)動程序150截取，并發(fā)送到遠程機器148，在遠程機器148，代理程序158(數(shù)據(jù)自適應(yīng)鑒定監(jiān)視器(daemon))線程將它們翻譯成在驅(qū)動程序堆頂層的文件系統(tǒng)操作。
對遠程事務(wù)文件系統(tǒng)操作，為打開文件，客戶重定向程序能，例如，使用COM/OLE將DTC事務(wù)對象160c編排到統(tǒng)一的字節(jié)流中，具有給服務(wù)器148的打開請求。可以看到，其他機制能達到等效的功能和/或結(jié)果，且雖然這里描述COM/OLE操作，本發(fā)明的這方面不限于COM/OLE。在COM/OLE實例中，事務(wù)對象160c附著于請求打開的客戶線程。注意，服務(wù)器機器148不關(guān)心事務(wù)在哪里開始的，只要它能將DTC事務(wù)對象160s的副本保持在其核心空間中。類似地，服務(wù)器148不在乎哪個線程或過程代表該事務(wù)工作。而是，在服務(wù)器148處的代理程序158將統(tǒng)一的字節(jié)流轉(zhuǎn)回到在核心中可得到的可用對象。此時，服務(wù)器把請求當作本地事務(wù)160s，并用在服務(wù)器上的副本DTC代理162s支持它，主要是告訴DTC為了后續(xù)的事務(wù)工作與服務(wù)器148聯(lián)系(而在這里TxF部件164作為資源管理器)。注意，因為服務(wù)器擁有此事務(wù)對象160s，因此，這是合適的。因為事務(wù)-ID處在分布式名字空間中，事務(wù)能在任何地方開始，但是基于事務(wù)-id的正確文件同步發(fā)生在服務(wù)器148上。
服務(wù)器實際上將文件系統(tǒng)請求當作就像是在本地情況的請求，而本地的TxF部件164處理事務(wù)的文件系統(tǒng)請求。但是，服務(wù)器148必須記住對應(yīng)的文件對象是針對被客戶146打開的文件，且該客戶具有高速緩存頁面。因此，在提交時刻，服務(wù)器148通知(通過重定向程序協(xié)議)客戶146刷新其高速緩存到服務(wù)器，并刷新任何能在客戶處打開的映射段(映射段的客戶跟蹤)。數(shù)據(jù)正常地以某些惰性方式(lazy fashion)到達服務(wù)器148，即每當它分頁出客戶的高速緩存/存儲器時到達。當數(shù)據(jù)到達時，它改寫在服務(wù)器上的高速緩存的副本。注意，這類似于以前的文件系統(tǒng)模型，其中多重打開的句柄或映射段互相改寫。
對基于重定向的文件建立操作，上述概念也能用于在網(wǎng)上編排ITransaction，在所述概念中用戶模式中的CreateFileEx將ITransaction對象編排(如通過DTC ItransactionTransmitter方法)到統(tǒng)一的字節(jié)集。因為在ITransactionTransmitter調(diào)用中不需要與事務(wù)管理器進行通信，其花費相對較少，因此對每次建立都能完成。但是，接收調(diào)用(如上述)確實需要與事務(wù)協(xié)調(diào)程序(或它的代理)通信，在基于重定向程序的情況，該程序是在遠程機器148上。然而，因為對于在整個網(wǎng)絡(luò)中每個事務(wù)，ITransactionReceiver只做一次(在服務(wù)器148上)，所以與事務(wù)協(xié)調(diào)程序162s的開銷并不明顯。
在此方式中，透明地支持事務(wù)的遠程文件訪問，即，使用遠程文件訪問，并通過在多個機器上建立應(yīng)用程序代理，應(yīng)用程序?qū)嶋H上能直接訪問網(wǎng)絡(luò)上任何處的文件。因此，同一事務(wù)能在同時涉及一個或多個本地過程及遠程過程。
對于單個客戶具有一個為遠程訪問打開的文件的情況，通?？梢詢?yōu)化重定向程序協(xié)議。在這種情況，通過保持該文件的本地盤高速緩存而避免了大量的網(wǎng)絡(luò)數(shù)據(jù)傳輸。僅當需要時(即文件關(guān)閉時)，才刷新改變。但是一旦另一客戶同時打開同一文件時，這樣的安排是無效的。機會主義的鎖定(oplock，主要是指示所有權(quán)的令牌)可完成此事，從而對上面的“關(guān)閉時更新”方案的改變最小。尤其是，在提交時刻，通常詢問客戶是否將改變刷新到服務(wù)器上去。在中斷時刻，客戶請求將客戶句柄標記成“毀滅的(doomed)”，使得一旦該句柄關(guān)閉，改變將簡單地丟棄。注意，重定向程序協(xié)議可以增強，使得服務(wù)器在某些環(huán)境讓客戶映射段無效，如同在本地情況。
名字空間隔離將一個事務(wù)的變化與其他事務(wù)隔離是事務(wù)的關(guān)鍵特性。在事務(wù)文件系統(tǒng)中，隔離不僅施加到存在文件中的數(shù)據(jù)(如上述)，還施加到文件名和文件組織下的目錄名的層次，按本發(fā)明的另外方面，提供了在文件/目錄名層次內(nèi)實現(xiàn)名字空間隔離的技術(shù)。該技術(shù)不需要在事務(wù)處理期間鎖定名字或目錄，并能與試圖用在事務(wù)中的文件上的非事務(wù)操作工作。
作為例子，考慮由事務(wù)建立而未被提交的文件。注意，可以建立目錄而不單是文件，但為簡單起見，本發(fā)明主要關(guān)于文件討論。然而應(yīng)該理解，關(guān)于下面敘述的名字空間操作，通常能等效地處理文件與目錄。事務(wù)建立的文件(或目錄)應(yīng)能用于沒有限制地建立事務(wù)，但應(yīng)不能為其他事務(wù)(如試圖打開它或列出其父目錄的事務(wù))可視。僅當建立的事務(wù)提交時，該文件才能被其他事務(wù)看到，若它中斷了，則該文件對任何人都不可見。非事務(wù)(如請求父目錄列舉)將看到這種文件，或者，使這種文件在提交前對非事務(wù)不可見也是可能的。
類似地，若文件(或目錄)被尚未提交的事務(wù)刪除，被刪文件需要繼續(xù)對其他事務(wù)可訪問，就像在提交時刻以前此刪除從未發(fā)生。但是，刪除事務(wù)將看到刪除的效果，并能夠在其空間中用相同的名字建立不同的文件。提交以后，被刪除的文件被去除。非事務(wù)將看到刪除的效果，即看不到被刪的文件，但非事務(wù)不能建立帶有與由非提交事務(wù)所刪除的文件有同樣名字的新文件，以避免由于刪除文件/目錄的事務(wù)中斷或刪除撤消而產(chǎn)生沖突。而且還可以將非事務(wù)當作好象是不同的事務(wù)進行處理，因而繼續(xù)看到被事務(wù)刪除的文件，但這并不是很好。
此外，如果文件(或目錄)被事務(wù)改名，對其他事務(wù)繼續(xù)可用具有原始目錄中的原始名字的該文件，新名字對其他事務(wù)不可見。做改名的事務(wù)將看到改名的效果，且可以使用老名字建立不同的文件。注意改名本質(zhì)上是建立新鏈接和刪除老的鏈接的組合。
為完成名字空間的隔離以處理上述情況，本發(fā)明保存名字空間的狀態(tài)以在事務(wù)處理期間為其他事務(wù)所用。為此，如圖16-18所示，建立稱為隔離目錄1701-1704的各個目錄，并將其鏈接到由執(zhí)行名字空間操作的事務(wù)改變的對應(yīng)NTFS目錄。尤其是，每個隔離目錄(如1701)包括與父目錄(如目錄D3)的TxFSCB結(jié)構(gòu)有關(guān)的搜索結(jié)構(gòu)(如二進制搜索樹)。此外，隔離目錄搜索結(jié)構(gòu)，并且有關(guān)的處理例行程序包括支持增加一個項及用名字快速查找一個項的通用接口，且還支持目錄列舉算法。
這些隔離目錄包括受使名字空間改變的事務(wù)影響的各個名字，并且只是主存儲器結(jié)構(gòu)。結(jié)構(gòu)中的每個項還包括與該名字相關(guān)的事務(wù)ID(Tid)，和可見性配置，它有兩個標志，對事務(wù)Tid可見，或?qū)ζ渌聞?wù)可見。這些可見性標志中的一個或兩個都可以分別設(shè)置。隔離目錄結(jié)構(gòu)還包括短名字/長名字標志，其中如果一個配對可用，該結(jié)構(gòu)包括指向?qū)?yīng)于該配對名字的結(jié)構(gòu)的指針。還提供一個標志指出名字由Tid保持，而其他事務(wù)不能請求它；一個Fid(用于對刪除的和改名的名字重定向建立())；和其他信息，即NTFS復(fù)制信息如時間標記和用于目錄列舉的類似標記。為了空間使用效率，結(jié)構(gòu)可以分成名字，指向該信息的指針，指向其他名字的指針，和其他信息。這導(dǎo)致單組其他信息被兩個名字共享。
作為隔離目錄如何使用的例子，如圖16所示，如果文件F3被事務(wù)T1刪除，文件F3的名字和各種信息在名字從NTFS目錄D3去除(幾乎)同時被加到隔離目錄1701。注意，為了刪除NTFS中的文件，打開文件被標記為刪除，文件系統(tǒng)關(guān)閉該文件而維持打開句柄的計數(shù)，并當沒有句柄保持打開時執(zhí)行刪除操作。此外注意，隔離目錄1701可能由于此事務(wù)T1的或另外事務(wù)(如T2)更早的操作已經(jīng)存在，或者在需要支持此刪除操作時建立。下面參考圖19的流程圖來進一步描述刪除操作。
使用隔離目錄1701來處理由不同事務(wù)(例如T2)對該文件F3的后續(xù)訪問，這樣，事務(wù)T2將繼續(xù)看見文件F3。然而，如果刪除文件F3的同一事務(wù)T1(或非事務(wù))查找文件F3，它將不能找到該文件。為了處理這些情況，如上所述，為此文件維持該文件的名字、其可見性配置、刪除文件的事務(wù)ID、重定向文件的ID、$TxF文件標識符(例如，單調(diào)增加序號)和復(fù)制的信息(數(shù)據(jù)標記、大小、屬性)。
圖19提供了處理對打開文件刪除請求的通用邏輯表示。注意圖19和類似的流程圖針對提供如何使用隔離目錄的理解進行了簡化，并且不應(yīng)認為是基礎(chǔ)代碼的精確表示，并沒有包括特別情況、差錯處理等等。在任何情況，在步驟1900開始，在事務(wù)處理及非事務(wù)處理請求實體之間作出區(qū)分，因為事務(wù)處理的用戶將導(dǎo)致不同于非事務(wù)處理的用戶的刪除操作的操作。如果非事務(wù)請求刪除一個文件(由其句柄識別)，刪除以另外的正常方式執(zhí)行，即在步驟1902指定的文件從盤中被刪除。當最后的句柄關(guān)閉時刪除開始。
若事務(wù)(如Tid1)在步驟1900請求刪除，則執(zhí)行步驟1904，它主要是改名文件。例如，如圖16所示，具有任意名(如“0”)的鏈接加到隱含的目錄168($TxF)，它鏈接到在主文件表130(圖11)中的文件記錄。同時，來自刪除的文件F3的鏈接從父目錄D3中去除。
然后在步驟1906，刪除信息被記錄到刪除記錄中，即文件名F3，對原始父目錄和新的鏈接信息的參考，如果在刪除該文件的事務(wù)提交以前系統(tǒng)崩潰，該事務(wù)將中斷，而日志通過簡單地如上述改名，即通過恢復(fù)以前的鏈接($TxF目錄沒有了，因為它是存儲器內(nèi)結(jié)構(gòu))正確地恢復(fù)該文件。
按照本發(fā)明，該文件信息隨后加到與正常目錄D3鏈接的隔離目錄樹1701。隔離目錄樹1701可能與正常目錄相關(guān)地已經(jīng)存在，但若沒有，就建立它。執(zhí)行步驟1910適當?shù)卣{(diào)節(jié)可見性配置標志以指出該事務(wù)Tid1請求刪除此文件，所以此文件對其他事務(wù)仍可見，但對Tid1不可見。在步驟1912，任意命名的鏈接被加到隨后將從盤刪除(在事務(wù)提交以后)的文件表中。
當事務(wù)終止時，對應(yīng)于該事務(wù)的名字項從隔離目錄中去除，而當隔離目錄中不存在任何項時，將將隔離目錄刪除。注意，若系統(tǒng)崩潰，存儲器內(nèi)結(jié)構(gòu)的隔離目錄就丟失。但是，因為系統(tǒng)崩潰中斷了未提交的事務(wù)，隔離目錄不再需要隔離，而日志文件的打開合適地復(fù)位了文件的狀態(tài)。
文件的建立有些類似于刪除，當文件由一個事務(wù)(如Tid2)在一個目錄中建立時，名字實際上加到鏈接(父)NTFS目錄的隔離目錄中。對其他事務(wù)，由于為打開該文件所作的可見性標志設(shè)置，或在事務(wù)提交之前列出其父NTFS目錄時，該文件名字被濾掉。對Tid2和非事務(wù)，建立的文件在其被提交前是可見的。
命名的項在其加入以后可以被事務(wù)修改。例如，若一個文件被刪除且另一文件使用同樣名字建立，建立將修改項的狀態(tài)，這樣其他事務(wù)將繼續(xù)看到在刪除前存在的文件，但此事務(wù)將看到它剛建立的文件。注意，在NTFS或隔離目錄上沒有保持將事務(wù)級鎖定。這使得系統(tǒng)還保持基文件系統(tǒng)的同時性。
如圖18所示，若事務(wù)Tid2建立文件F6(在正常的父目錄內(nèi)請求建立)，則F6在目錄D4中建立，且因而一個項加到父目錄D4相關(guān)的隔離目錄1702。如需要，建立隔離目錄1702。適當?shù)卣{(diào)節(jié)標志以反映Tid2建立的狀態(tài)(即對Tid2可見但對其他事務(wù)不可見)以及對Tid2保存的名字。注意，事務(wù)Tid2在提交以前也能刪除新建立的文件F6，在這種情況它將不能被Tid2及其他事務(wù)看到。處理這種建立-然后-刪除操作的一個方法是從目錄D4去除該項和從隔離目錄1702去除該項。另外方法是將該項留在隔離目錄1702中，而它的配置標志(disposition flag)設(shè)置成對創(chuàng)建該文件的Tid2及其他事務(wù)均不可見，這樣防止在Tid2提交或中斷前該文件名被其他事務(wù)使用。
回到典型的情況，其中F6被事務(wù)Tid2建立但未被刪除，當(且如果)事務(wù)Tid2提交或中斷，隔離的項從隔離目錄1702去除，從而使得被建立的文件F6在提交的情況對所有事務(wù)均可見。如果事務(wù)T2中斷，該文件從正常NTFS目錄D4刪除。每個隔離的項保留直到與其相關(guān)的事務(wù)結(jié)束，且在提交或或中斷時被去除。為便于去除，每個事務(wù)保留一個TxFSCB指針表，其中該事務(wù)至少具有一個這種項。事務(wù)還在每個TxFSCB上適當?shù)卦黾雍蜏p少參照計數(shù)，使得TxFSCB被使用它們的事務(wù)所掌握。
圖20提供處理對建立一個文件的請求的通用邏輯的表示，其中請求是New_File_Create(請求的類型是若文件帶有與已經(jīng)存在文件相同的文件名，則不允許建立)。在步驟2000開始，執(zhí)行測試以確定該文件名(如圖17的F6)是否已出現(xiàn)在正常的父目錄中，如父目錄D4。若是，文件不能建立，且在步驟2000轉(zhuǎn)移到步驟2002，返回一個錯誤，若在父目錄D4中未找到文件F6，有可能該文件名已經(jīng)被事務(wù)使用。為測試這點，步驟2000轉(zhuǎn)移到步驟2004，其中搜索與D4有關(guān)的隔離目錄1702以尋找此文件名。若此文件F6(或隔離目錄)的項不存在，步驟2004轉(zhuǎn)移到步驟2006，在那里作出判斷是否事務(wù)正請求建立，或者是非事務(wù)請求。若非事務(wù)在請求，步驟2006轉(zhuǎn)移到步驟2018，其中文件在正常目錄D4中建立。否則，事務(wù)(如Tid2)請求建立，執(zhí)行步驟2010，從而將一個項加到隔離目錄1702(若對父目錄中不存在什么，則在建立隔離目錄1702之后)。然后步驟2014表示合適的標志設(shè)置，對此項獲得其他信息等。步驟2014隨后延續(xù)到步驟2018，其中文件F6在正常目錄D4中實際建立。注意，在NTFS中，在建立時定位文件，在主文件表中對此文件建立文件記錄，且建立記錄加到日志中。
在步驟2004，如果在隔離目錄1702找到此名字，則不允許建立，除非該指定的文件被正請求建立的同一Tid(如Tid2)刪除。以此方式，一個事務(wù)可以建立它所刪除的文件，但在建立和/或刪除該文件的事務(wù)提交或中斷之前，其他事務(wù)或非事務(wù)均不能使用該文件名。若找到，執(zhí)行步驟2012以測試標志狀態(tài)，判斷同一事務(wù)是否正請求建立。若是，步驟2012轉(zhuǎn)移到步驟2014以改變對此項的標志狀態(tài)，實質(zhì)上現(xiàn)在表示“由Tid2建立”(對Tid2可見，對其他不可見)而非“由Tid2刪除”(對Tid2不可見，對其他可能可見)。若另一事務(wù)或非事務(wù)請求建立，步驟2012轉(zhuǎn)移到步驟2016返回一個錯誤，指出一個事務(wù)保留此文件名。
圖18表示事務(wù)文件改名操作，它本質(zhì)上是建立鏈接請求和刪除鏈接請求的組合。因此，若事務(wù)T1將文件“\D2\D3\F2”改名成“\D2\D3\D4\F7”，則鏈接F2從目錄D3被刪除，并在目錄D4中建立鏈接F7。但是，因為在改名中涉及到事務(wù)，在合適的隔離目錄1703和1704中反映這些操作。注意，文件可以在同一父目錄內(nèi)改名，或使文件改名而在不同的目錄中具有相同文件名。
按照本發(fā)明，對文件的事務(wù)處理改名，提供涉及改名的每個父目錄的隔離目錄，例如一個指出事務(wù)的刪除操作，一個指出事務(wù)的建立操作。注意，在同一父目錄中的改名只需要一個隔離目錄，一個項用于老文件的刪除，一個用于新文件的建立。如上述從圖19(刪除)和20(建立)能理解，其他事務(wù)仍看到該文件，好象文件仍未改名，而在事務(wù)提交之前看不到改名后的文件。如果事務(wù)中斷，其他事務(wù)將看不到任何表示曾經(jīng)發(fā)生過改名的跡象，除了可能看到，使用中的文件名在該事務(wù)的活動周期暫時被保留。
最后，圖21-22表示例如在試圖打開文件或獲得其文件信息(如作為列舉的一部分)時，一個事務(wù)是否將看到指定的文件，這取決于文件的狀態(tài)。步驟2100表示對文件是否在正常目錄中的測試。若是，需要搜索隔離目錄(如果存在)，尋找該文件的項，以確定該文件對請求者是否可見(步驟2102)。如不在正常目錄中，文件有可能被正在進行的事務(wù)從正常目錄中刪除，這在下面圖22中處理。
若該文件在正常目錄中(步驟2100)，而該文件的項不在隔離目錄中，步驟2102，則它是普通可訪問的文件，即它還未由沒有提交的事務(wù)建立。若是這樣，文件系統(tǒng)將好象在事務(wù)以前其已創(chuàng)建操作(由步驟2104表示)，即可返回文件句柄(如在文件打開請求的情況)，或文件信息可以從主文件表中的信息返回(如在列舉請求的情況)。
若該文件的一個項在隔離目錄樹中，它必須由進行的事務(wù)建立，而步驟2102轉(zhuǎn)移到2106，在那執(zhí)行測試，判斷建立文件的事務(wù)是否為正請求訪問或請求信息的同一事務(wù)。若是，步驟2106轉(zhuǎn)移到2108，測試可見性配置標志(是否對此Tid可見)。若可見，則返回文件句柄(或文件信息)給請求的事務(wù)(步驟2110)。注意，在這里的實現(xiàn)中，應(yīng)該不是文件在正常目錄且項在隔離目錄中的情況，(因為是由事務(wù)建立)，但標志指出，該文件應(yīng)對建立它的事務(wù)不可見。因此，在這里的實施中，步驟2108的測試基本上是不必要的，除非用于檢測正常和/或隔離目錄的破壞等。
若文件的一個項在正常目錄(步驟2100)及隔離目錄樹(步驟2102)中，但步驟2106判定，同樣的事務(wù)未作出請求，則在本實現(xiàn)中，文件在步驟2114中可以是或可以不是可見的。若不可見，除非其他事務(wù)請求的部分是使用文件名，否則步驟2116可認為該文件未找到，返回指出該文件被其他事務(wù)使用的錯誤信息。例如，若找不到指定文件，試圖建立新文件的這種打開文件請求類型將失敗，因為名字被使用。若在步驟2114為其他事務(wù)可見(文件刪除后被建立)，使用重定向Fid從$TxF目錄打開被刪除的文件(步驟2118)。
圖22處理文件不在正常目錄中的情況。若一個尚未提交或中斷的事務(wù)已刪除一個文件，對該文件的項將在隔離目錄中，而那個事務(wù)不能看見該文件，但其他事務(wù)能看見。步驟2200測試，對該文件的項是否不在該隔離目錄中(由圖21的步驟2100不在正常目錄中)，若不在，在步驟2202該文件找不到并相應(yīng)地處理。
若相反，在步驟2200中該名字出現(xiàn)在隔離目錄中，則事務(wù)已刪除它。步驟2204測試是否刪除該文件的同一事務(wù)在請求訪問該文件(或請求其信息)。如果是，在步驟2212文件對刪除其的事務(wù)是不可見的，并且這樣存在沒有找到的狀態(tài)(步驟2206)。注意如果由于某些原因，該文件對事務(wù)可見，則將存在錯誤。
如果在步驟2204與刪除該文件不同的事務(wù)請求對該文件的訪問(或其信息)。如果如在隨后的步驟2212所測試的文件對其他事務(wù)可見的話，步驟2214返回該文件的句柄，或文件信息(從保存的文件ID，或如下所述的Fid，包括復(fù)制的信息)。
另一種可能性是一個進行的事務(wù)建立并隨后刪除一個文件，因而該文件不在正常的目錄中。如上所述，文件名或者處理成為其他事務(wù)可用，或為進行的事務(wù)保留，直到該事務(wù)提交或中斷。對于前者，可以通過在建立文件的事務(wù)刪除它時，簡單地將該文件的項從正常目錄及隔離目錄中去除未實現(xiàn)；注意，若這種文件項從隔離目錄中去除，則將不達到步驟2212。對于后者，可以通過在刪除時將文件從正常目錄中去除而將該文件的項留在隔離目錄，并設(shè)置標志指出對任何事務(wù)都不可見來實現(xiàn)。可以理解，這是可能的，因為可見性配置標志是獨立設(shè)置的(即它們不是互相排斥的)。但是，如果文件留在隔離目錄中并標記為對其他事務(wù)(和對建立它的事務(wù))不可見，則在步驟2216存在找不到文件的狀態(tài)，但文件名為進行的事務(wù)保留。
在此方式中，本發(fā)明方便了整理搜索，如使用NTFS調(diào)整規(guī)則和NTFS例行程序以調(diào)整次序?qū)ふ蚁乱粋€名字。本發(fā)明在空間方面是有效的，并允許并發(fā)的讀/寫訪問。
注意，出于它看到或看不到的目的，非事務(wù)僅看到在正常目錄中的內(nèi)容。但是對于使用現(xiàn)有的文件名的目的，非事務(wù)不能使用為事務(wù)保留的文件名。為此，當非事務(wù)試圖建立具有在正常目錄中不存在的名字的文件時，如上所述檢查隔離目錄。
考慮到上面例子和描述，下面例子示出事務(wù)如何使用和修改隔離目錄中的項。首先，考慮事務(wù)Tid10，它在目錄X中建立名為YisAVeryLongName的新文件，即建立X\YisAVeryLongName。隔離目錄節(jié)加入下面兩個項NameYisAVeryLongName；Tid10；(對Tid可見TRUE，對其他可見FALSE)；LongNameTRUE；pairedNamePtrPtr到短名項ReservedTRUE；FidINVALID_ID；其他復(fù)制信息。
NameYisAVery
LongNameFALSE；pairedNamePtrPtr到長名項這保證了X的后續(xù)的目錄列舉如果是由Tid10以外的事務(wù)做的，將不返回這些名字，而非事務(wù)將看到這兩個名字。此外，如果另一事務(wù)Tid20試圖建立或打開兩個名字的任一個，該事務(wù)將得到從上述隔離結(jié)構(gòu)檢測的“File-already-exist-but-sharing-violation”錯誤。
如果非事務(wù)處理線程打開這些名字中任一個，如果為了寫，刪除或任何類型的修改而打開，它得到共享破壞的信息，這種非事務(wù)能只讀地打開它。這是由于上述分別強加的TxF的文件鎖定語義。
考慮第二個例子，從父目錄X事務(wù)處理刪除現(xiàn)有的文件YisAVeryLongName。在此例中在目錄X中還有此名字的短名鏈接(名字對情況，與鏈接刪除情況相反)。而且，該事務(wù)具有標識符Tid10，而隔離目錄具有下列兩個加入項目NameYisAVeryLongName；Tid10；(對Tid可見FALSE，對其他可見TRUE)；LongNameTRUE；pairedNamePtrPtr到短名項ReservedTRUE；Fid文件Id；其他復(fù)制信息。
NameYisAVeryLongNameFALSE；pairedNamePtrPtr到長名項這兩個鏈接也從目錄X的索引SCB刪除，但現(xiàn)在可以假設(shè)TxF保證文件未被物理上去除，因為在刪除前TxF將系統(tǒng)擁有的鏈接加到文件上。因此，兩個名字均不能為Tid10以外的任何事務(wù)用于建立新文件或新鏈接。這是因為Tid10能決定中斷和重新使用這些名字。而且，這些名字在目錄列舉或建立中對Tid10不可見，使Tid可用這兩個名字的任一個建立新鏈接/文件，這些名字對其他事務(wù)可見，這意味著這些事務(wù)能使用該文件ID(Fid)打開它們。非事務(wù)處理的用戶不能看到這些文件，他們也不能使用這些名字來建立新的文件。
在第三例子中，認為第一例子已經(jīng)發(fā)生，即文件已經(jīng)建立。然而，因為該名字對事務(wù)Tid10可見，Tid10能自由地打開該文件并刪除它。若Tid10打開該文件用于寫，并隨后刪除它，刪除后的隔離項如下NameYisAVeryLongName；Tid10；(對Tid可見FALSE，對其他可見FALSE)；LongNameTRUE；pairedNamePtrPtr到短名項ReservedTRUE；FidINVALID_ID；沒有復(fù)制信息。
NameYisAVeryLongNameFALSE；pairedNamePtrPtr到長名項這些項對該事務(wù)保留名字，但使它對任何事務(wù)都不可見，注意，執(zhí)行保留以允許退回到工作。
浮動存儲器映射段本發(fā)明的另外方面是定位于解決一個問題，其中應(yīng)用程序?qū)σ粋€或多個為寫訪問而打開的文件上執(zhí)行存儲器映射，而不覺察包括該應(yīng)用程序的事務(wù)已中斷(或提交)。例如，當分布式事務(wù)在網(wǎng)絡(luò)的另一個網(wǎng)絡(luò)節(jié)點中斷時會發(fā)生這樣情況。在那時，應(yīng)用程序工作情況會不佳或有破壞性。
當應(yīng)用程序?qū)懺L問而打開的文件上執(zhí)行存儲器映射，并不覺察其有關(guān)的事務(wù)已中斷(或提交)，和/或工作情況會不佳或有破壞性，另一寫程序能打開仍然是存儲器映射的文件用于寫訪問。因此與文件數(shù)據(jù)能發(fā)生沖突，因為存在多個同時的寫程序。更具體地，當由應(yīng)用程序執(zhí)行時，存儲器映射指使用段對象(共享存儲器塊)將文件映射到過程地址空間。若應(yīng)用程序修改一頁，存儲管理器能在正常頁面操作期間將改變寫回到盤上的文件中，或者，應(yīng)用程序能直接引起一次刷新。雖然在事務(wù)的環(huán)境中不希望這樣，但允許應(yīng)用程序執(zhí)行存儲器映射，因此可能通過另外的事務(wù)應(yīng)用程序引起對為寫訪問而打開的文件的寫操作。
知道事務(wù)何時提交或退出，并且例如清除受該事務(wù)影響的數(shù)據(jù)結(jié)構(gòu)的文件系統(tǒng)可以詢問存儲管理器以確定事務(wù)的應(yīng)用過程(或多個過程)是否是存儲器映射，即是否已經(jīng)建立一個段句柄。如果存在任何這種應(yīng)用程序，不知道該應(yīng)用程序操作狀態(tài)的文件系統(tǒng)不能直接關(guān)閉該應(yīng)用程序或保證它不會繼續(xù)寫到映射段。
圖23示出一個方法，其中文件系統(tǒng)62防止應(yīng)用程序180(不再是事務(wù)的一部分)寫到為另一應(yīng)用程序182打開用于寫訪問的映射文件。為此，文件系統(tǒng)調(diào)節(jié)段控制塊(SCB)188，各個應(yīng)用程序180，182的文件對象184、186指向不同的段對象指針190、192。無效事務(wù)應(yīng)用程序1(180)的段對象指針190是空的，而有效事務(wù)應(yīng)用程序2(182)的段對象指針192具有指向用于該應(yīng)用程序182的存儲器196的指針。這使得存儲器段194浮動。
無效事務(wù)應(yīng)用程序180能持續(xù)對浮動的存儲器段讀或?qū)?，但它不再對?yīng)于該文件。同時，一旦在高速緩存/存儲管理器114通過代表有效應(yīng)用程序182的文件系統(tǒng)62發(fā)現(xiàn)頁面存在錯誤，適當?shù)奶摂M存儲器頁面198(及由應(yīng)用程序182使用的存儲器196)用從事務(wù)處理的正確文件(如保存在TOPS流版本中的正確頁面)來的數(shù)據(jù)，或從盤上文件來的數(shù)據(jù)進行填充。類似的，當存儲管理器114指令時，文件系統(tǒng)62將由有效應(yīng)用程序改變的頁面寫到盤112中。
但是，對于映射到無效應(yīng)用程序180的段中的頁面，任何從達到對應(yīng)于存儲器段194的文件系統(tǒng)62的存儲管理器114來的寫請求被文件系統(tǒng)62接受，但實際上不寫入盤，因此，映射的存儲器是浮動的段；可以允許其寫入存儲器，但其改變決不刷新到盤中。由存儲管理器114對從盤112來的頁面請求失敗導(dǎo)致返回零。因此，段194的此版本不再由盤上的文件返回。以此方式，有效事務(wù)的應(yīng)用程序的數(shù)據(jù)文件與由無效應(yīng)用程序?qū)τ成湮募臄?shù)據(jù)改變相隔離。
另外還可能將存儲器的映射段改變成對無效應(yīng)用程序不能訪問或只讀。從而由無效應(yīng)用程序的寫導(dǎo)致訪問破壞。如果讀是允許的，每當由有效應(yīng)用程序作出的改變在段194中錯誤，無效應(yīng)用程序能看到這些改變。
注意，任意上述解決方法能引起無效的應(yīng)用程序180崩潰，而有效應(yīng)用程序182的數(shù)據(jù)被適當?shù)馗綦x。為避免破壞無效應(yīng)用程序180，作出的改變被寫到盤上另一文件，但是，目前支持這種后事務(wù)處理的版本被認為對這種應(yīng)用程序是不必要的開銷增加。
TxF日志記錄格式<pre listing-type="program-listing"><![CDATA[　　//log record types that are known to the recovery manager.　　typedef enum {　　TxfLogRecTypeRedo，　　TxfLogRecTypeUndo，　　TxfLogRecTypePrepare，　　TxfLogRecTypeAbort，　　TxfLogRecTypeCommit，　　}TXF_LOGREC_TYPE；　　typedef enum {　　TxfLogRecActionCreateFile，　　TxfLogRecActionDeleteFile，　　TxfLogRecActionWriteFile，　　TxfLogRecActionOverwriteFile，　　TxfLogRecActionFcbInfoUpdateFile，　　TxfLogRecActionTemporaryBitChangeFile，　　TxfLogRecActionUpdateDupInfo，　　TxfLogRecActionTruncateFile，　　TxfLogRecActionRestoreFilesizes，　　TxfLogRecActionCancelRecord，　　TxfLogRecActionTestPrint}TXF_LOGREC_ACTION；　　typedef struct {　　TXF_LOGREC_TYPE Type；　　TXF_LOGREC_ACTION Action；　　TXF_TRANS_ID TransId；　　}TXF_LOGREC，*PTXF_LOGREC；　　/+　　typedef struct {　　TXF_LOGREC_HDR header；　　char data[1]；　　}TXF_LOGREC，*PTXF_LOGREC；　　*/　　//　　//Delete File log record.　　//　　//　　//The Long name and the short name are laid out　　//immediately after the record.　　//　　typedef struct_TXF_DELETE_FILE_UNDO_LOGREC {　　TXF_LOGREC Header；　　//　　//See below for flag values　　//　　USHORT Flags；　　//　　//ShortNameLength is 0 if there′s no short name.//The short name begins right after the　　//FileName.FileName ends.　　//It′s at PWCHAR FileName.FileName +　　//FileName.FileNameLength.　　//ShortNameLength is in unicode chars.　　//　　USHORTShortNameLength；　　//　　//MungedFileNumber to which the rename happened.　　//　　ULONG MungedFileNumber；　　//　　//The Txf subdirectory to which the rename happened.　　//　　ULONG SubDirNumber；　　//　　//The long/combined name with valid dup info，parent　　//directory，length　　//etc.　　//　　FILE_NAME FileName；　　//　　//Don′t add any fields after this.　　//}*PTXF_DELETE_FILE_UNDO_LOGREC，　　TXF_DELETE_FILE_UNDO_LOGREC；　　//　　//TRUE if the file is a directory.　　//　　#define TXF_DELETE_FILE_UNDO_FLAGS_DIRECTORY 0x01　　//　　//TRUE if this delete operation had stored the Fid flags.　　//　　#define TXF_DELETE_FILE_UNDO_FLAGS_FID_STORED0x02　　//　　//IgnoreCase flag for the CCB that opened the name for　　//delete.　　//　　#defitne TXF_DELETE_FILE_UNDO_FLAGS_IGNORE_CASE 0x04　　//　　//Create-File undo log record.　　//　　//The Long name and the short name are laid out　　//immediately after the record.　　//　　typedef struct_TXF_CREATE_FILE_UNDO_LOGREC {　　TXF_LOGREC Header；　　FILE_REFERENCE ParentFid；//　　//LongNameLength is in unicode characters.　　//　　USHORTLongNameLength；　　//　　/LongNameOffset＝sizeof(struct　　//_TXF_CREATE_FILE_UNDO_LOGREC)　　//　　//　　//See below for flag values　　//　　USHORTFlags；　　//　　//ShortNameLength is 0 if there′s no short name.　　//Length is in unicode chars.　　//　　USHORT ShortNameLength；　　//　　//ShortNameOffset is sizeof(struct　　//_TXF_CREATE_FILE_UNDO_LOGREC) +　　//LongNameLength*sizeof(WCHAR)　　//　　USHORT Reserved1；　　ULONG Reserved2；}*PTXF_CREATE_FILE_UNDO_LOGREC，　　TXF_CREATE_FILE_UNDO_LOGREC；　　//　　//TRUE if the file is a directory.　　//　　#define TXF_CREATE_FILE_UNDO_FLAGS_DIRECTORY 0x01　　//　　//IgnoreCase flag for the CCB that created the name.　　//　　#define TXF_CREATE_FILE_UNDO_FLAGS_IGNORE_CASE 0x02　　//　　//Overwrite-File undo log record.　　//　　typedef struct_TXF_OVERWRITE_FILE_UNDO_LOGREC {　　TXF_LOGREC Header；　　//　　//File reference of the file that was overwritten　　//　　FILE_REFERENCE Fid；　　//　　//File reference of the TxF file that was created in　　//the TxF directory.//　　 FILE_REFERENCE TxfFileFid；　　 //　　 //MungedFileNumber of the TxF file that was created in　　　 //the TxF directory.　　 //　　 ULONG MungedFileNumber；　　 //　　 //The Txf subdirectory in which the TxF file was　　 //created.　　 //　　 ULONG SubDirNumber；　　 USHORT Flags；　　 USHORT Reserved1；　　 ULONG Reserved2；　　}*PTXF_OVERWRITE_FILE_UNDO_LOGREC，　　TXF_OVERWRITE_FILE_UNDO_LOGREC；　　//　　//FcbInfoUpdate undo log record.It is undone　　//uncorditionally without checking the TxfLsn in the　　//standard-info.　　//　　typedef struct_TXF_FCB_INFO_UPDATE_UNDO_LOGREC {TXF_LOGRECHeader；　　 //　　 //File reference of the file that was overwritten　　 //　　 FILE_REFERENCE Fid；　　 //　　 //Fcb Info to be restored on undo.　　 //　　 DUPLICATED_INFORMATION FcbInfo；　　}*PTXF_FCB_INFO_UPDATE_UNDO_LOGREC，　　TXF_FCB_INFO_UPDATE_UNDO_LOGREC；　　//　　//FcbInfoUpdate undo log record.It is undone　　//unconditionally without checking the TxfLsn in the　　//standard-info.　　//　　typedef struct_TXF_TEMPORARY_BIT_CHANGE_UNDO_LOGREC {　　TXF_LOGREC Header；　　//　　//File reference of the file that was overwritten　　//FILE_REFERENCE Fid；　　 ULONG PreviousBitValue；　　 //　　 //Attribute name length is 0 if this is the default　　 //data stream.　　 //Length is in unicode chars.　　 //Attribute name follows the log record，if present.　　 //　　 USHORTAttrNameLength；　　 WCHAR AttrName[1]；　　}*PTXF_TEMPORARY_BIT_CHANGE_UNDO_LOGREC，　　TXF_TEMPORARY_BIT_CHANGE_UNDO_LOGREC；　　//　　//UpdateDupInfo undo log record.　　//　　//The Long name is laid out immediately after the record.　　//　　typedef struct_TXF_UPDATE_DUPINFO_UNDO_LOGREC {　　TXF_LOGREC Header；　　//　　//Fid of the parent directory.　　//　　FILE REFERENCE ParentFid；//　　 //LongNameLength is in unicode characters.　　 //　　 USHORT LongNameLength；　　 //　　 //See below for flags.　　 //　　 USHORT Flags；　　 //　　 //Duplicated information.　　 //　　 DUPLICATED_INFORMATION DupInfo；　　 WCHAR LongName[1]；　　}*PTXF_UPDATE_DUPINFO_UNDO_LOGREC，　　TXF_UPDATE_DUPINFO_UNDO_LOGREC；　　#define TXF_UPDATE_DUPINFO_UNDO_FLAGS_DIRECTORY 0x0001　　//　　//Truncate undo log record.　　//　　//The attribute name is laid out immediately after the　　//record.　　//　　typedef struct_TXF_TRUNCATION_UNDO_LOGREC {TXF_LOGRECHeader；　　 //　　 //Fid of the file.　　 //　　 FILE_REFERENCE Fid；　　 LONGLONG ValidDataLength；　　 LONGLONG FileSize；　　 // //Attribute name length is 0 if this is the default　　 //data stream.　　 //Length is in unicode chars.　　 //Attribute name fc lows the log record，if present.　　 //　　 USHORT AttrNameLength；　　 WCHAR AttrName[1]；　　}*PTXF_TRUNCATION_UNDO_LOGREC，TXF_TRUNCATION_UNDO_LOGREC；　　//　　//Restore file sizes undo log record.　　//　　//The attribute name is laid out immediately after the　　//record.　　//　　typedef struct_TXF_RESTORE_FILE_SIZES_UNDO_LOGREC {　　TXF_LOGREC Header；//　　 //Fid of the file.　　 //　　 FILE_REFERENCE Fid；　　 LONGLONGValidDataLength；　　 LONGLONGFileSize；　　 //　　 //Attribute name length is 0 if this is the default　　 //data stream.　　 //Length is in unicode chars.　　 //Attribute name follows the log record，if present.　　 //　　 USHORTAttrNameLength；　　 WCHAR AttrName[1]；　　}*PTXF_RESTORE_FILE_SIZES_UNDO_LOGREC，　　TXF_RESTORE_FILE_SIZES_UNDO_LOGREC；　　//　　//Define the format of the Change Table entries，and some　　//related contents.　　//　　#define TOPS_SECTOR_SIZE(512)　　#define TOPS_PAGE_SIZE (4096)　　#define TOPS_PAGE_SHIFT (12)#define TOPS_SECTORS_PER_PAGE (TOPS_PAGE_SIZE/　　TOPS_SECTOR_SIZE)　　#define TOPS_MAXIMUM_FLUSH_SIZE(0x10000)　　typedef struct_CHANGE_ENTRY {　　//　　//These two fields describe the virtual addrress of the　　//displaced range of the stream.　　//　　ULONGLONG VirtualPageNumber；　　ULONG NumberPages；　　//　　//This is the starting page number in the Tops stream　　//to where the old pages were written.　　// 　　 ULONG TopsPageNumber；　　//　　//This is the Lsn of the log record describing this　　//change.　　//　　CLFS_LSN Lsn；　　//　　//SequenceNumber being written into all bytes of the　　//undo pages covered　　//by this change.　　//UCHAR SequenceNumber；　　 //　　 //May as well reserve bytes here for alignment，since　　 //the size will always round to quad word anyway.　　 //　　 UCHAR Reserved[7]；　　 //　　 //Finally，these are the displaced bytes of data，　　 //allowing torn write detection in the Tops stream.　　 //Enough are allocated here for one page，yet　　 //additional bytes will be allocated if NumberPages is　　 //greater than one.　　 //　　 UCHAR DisplacedBytes[TOPS_SECTORS_PER_PAGE]；　　}CHANGE_ENTRY，*PCHANGE_ENTRY；　　//　　//Create-File undo log record.　　//　　//The Long name and the short name are laid out　　//immediately after the record.　　//　　typedef struct_TXF_WRITE_FILE_UNDO_LOGREC {　　TXF LOGREC Header；//　　 //File Reference for file undo data was captured from.　　 //　　 FILE_REFERENCE FileReference；　　 //　　 //Describe where the undo data was written and store　　 //the displaced bytes which were replaced by a　　 //sequence number.　　 //　　 CHANGE_ENTRY ChangeEntry；　　}TXF_WRITE_FILE_UNDO_LOGREC，*PTXF_WRITE_FILE_UNDC_LOGREC；]]></pre>如上面詳細描述可見，提供了一個事務(wù)處理文件系統(tǒng)及方法，使得應(yīng)用程序能容易地對一個或多個文件執(zhí)行多重事務(wù)操作。多重文件系統(tǒng)操作在文件系統(tǒng)中以事務(wù)處理方式互相結(jié)合，使得操作要么一起提交，要么任何部分的活動都被撤消。此外一個事務(wù)的操作和數(shù)據(jù)改變與另外事務(wù)的操作和數(shù)據(jù)改變互相隔離。因此，例如本發(fā)明能以快速，有效和安全的方式將網(wǎng)站作為由文件系統(tǒng)部件處理的單個事務(wù)進行更新。同時，在事務(wù)提交前進行中的改變互相隔離。
然而本發(fā)明易受各種修改和改變的結(jié)構(gòu)的影響，某些這里說明的實施例在圖中示出，并在上面詳細描述。但是應(yīng)該理解，這并不是要將本發(fā)明限制在特定的形式或所揭示的形式，而相反，本發(fā)明覆蓋所有修改、另外結(jié)構(gòu)和落在本發(fā)明的精神和范圍內(nèi)的等效事物。
權(quán)利要求
1.一個具有計算機可執(zhí)行指令的計算機可讀媒體，其特征在于，包括在文件系統(tǒng)中接收信息，所述信息指出文件與第一事務(wù)相關(guān)；在文件系統(tǒng)中接收第一請求，以執(zhí)行對文件的名字空間有關(guān)的操作；將有關(guān)文件的信息存入隔離目錄中；接收針對該文件的第二請求；和訪問隔離目錄以判定關(guān)于該第二請求是否有文件存在。
2.如權(quán)利要求1所述的計算機可讀媒體，其特征在于，還包括用于接收第一事務(wù)完成的信息，及去除存儲在隔離目錄中的文件信息的計算機可執(zhí)行指令。
3.如權(quán)利要求1所述的計算機可讀媒體，其特征在于，所述第一請求包括來自第一事務(wù)的刪除該文件的請求，所述文件具有父目錄，并且其中，隔離目錄與父目錄相關(guān)。
4.如權(quán)利要求3所述的計算機可讀媒體，其特征在于，還包括用于接收第一事務(wù)已經(jīng)提交的信息，及去除存儲在隔離目錄中的文件信息的計算機可執(zhí)行指令。
5.如權(quán)利要求3所述的計算機可讀媒體，其特征在于，還包括用于接收第一事務(wù)已經(jīng)中斷的信息，去除存儲在隔離目錄中的文件信息，及將文件信息存入該文件的父目錄的計算機可執(zhí)行指令。
6.如權(quán)利要求1所述的計算機可讀媒體，其特征在于，所述第二請求包括來自第一事務(wù)的對文件信息的請求，且其中訪問隔離目錄以確定與第一事務(wù)有關(guān)的文件不存在。
7.如權(quán)利要求1所述的計算機可讀媒體，其特征在于，所述第二請求包括來自第二事務(wù)訪問該文件的請求，并其中訪問隔離目錄以判定與第二事務(wù)有關(guān)的文件存在。
8.如權(quán)利要求7所述的計算機可讀媒體，其特征在于，還具有計算機可執(zhí)行指令，用于返回一個文件句柄給第二事務(wù)。
9.如權(quán)利要求7所述的計算機可讀媒體，其特征在于，還包括計算機可執(zhí)行指令，用于返回文件元數(shù)據(jù)信息給第二事務(wù)。
10.如權(quán)利要求1所述的計算機可讀媒體，其特征在于，該文件與父目錄有關(guān)，且還包括計算機可執(zhí)行指令，用于建立隔離目錄，并將該隔離目錄與該父目錄相聯(lián)系。
11.如權(quán)利要求1所述的計算機可讀媒體，其特征在于，所述第一請求包括來自第一事務(wù)在父目錄中建立該文件的請求。
12.如權(quán)利要求11所述的計算機可讀媒體，其特征在于，還包括計算機可執(zhí)行指令，用于接收指出第一事務(wù)已提交的信息；去除存在隔離目錄中的文件信息；并存儲文件信息到該文件的父目錄中。
13.如權(quán)利要求11所述的計算機可讀媒體，其特征在于，還包括計算機可執(zhí)行指令，用于接收指出第一事務(wù)已中斷的信息；并去除存在隔離目錄中的文件信息。
14.如權(quán)利要求11所述的計算機可讀媒體，其特征在于，所述第二請求包括來自第二事務(wù)對文件信息的請求，且其中訪問隔離目錄以判定不存在與第二事務(wù)有關(guān)的文件。
15.如權(quán)利要求11所述的計算機可讀媒體，其特征在于，所述第二請求包括來自第一事務(wù)訪問文件的請求，且其中訪問隔離目錄以判定存在與第一事務(wù)有關(guān)的文件。
16.如權(quán)利要求11所述的計算機可讀媒體，其特征在于，所述第二請求包括來自第一事務(wù)的文件信息的請求，且其中訪問隔離目錄以判定存在與第一事務(wù)有關(guān)的文件。
17.如權(quán)利要求16所述的計算機可讀媒體，其特征在于，還包括計算機可執(zhí)行指令，用于響應(yīng)第二請求返回文件元數(shù)據(jù)信息給第一事務(wù)。
全文摘要
本發(fā)明提供一個具有計算機可執(zhí)行指令的計算機可讀媒體，它包括在文件系統(tǒng)中接收信息，所述信息指出文件與第一事務(wù)相關(guān)；在文件系統(tǒng)中接收第一請求，以執(zhí)行對文件的名字空間有關(guān)的操作；將有關(guān)文件的信息存入隔離目錄中；接收針對該文件的第二請求；以及訪問隔離目錄以判定關(guān)于該第二請求是否有文件存在。因此，本發(fā)明加入事務(wù)機制到文件系統(tǒng)中，使得應(yīng)用程序能容易執(zhí)行對一個或多個文件的多重事務(wù)操作，克服了與外事務(wù)機制相關(guān)的問題。
文檔編號G06F12/00GK1746893SQ200510103699
公開日2006年3月15日 申請日期2001年3月16日 優(yōu)先權(quán)日2000年3月30日
發(fā)明者S·維爾馬, T·J·米勒, R·G·阿特金森 申請人:微軟公司