ＦｒｅｅＢＳＤ中Ｉ／Ｏ系統的研究與分析

摘要：FreeBSD操作系統提供了一個性能突出、便于擴展、靈活性高的經典I/O子系統。通過分析FreeBSD內核源代碼對I/O子系統進行了深入研究，并以一個讀請求的實例清晰地展示了其輸入/輸出操作的整個流程。

關鍵詞：輸入/輸出系統； FreeBSD； 虛擬文件系統層

中圖分類號：TP316.81文獻標志碼：A

文章編號：1001－3695(2007)07－0075－04

FreeBSD是一類穩定、高效、可靠的操作系統，它既可以用于大型服務器上，也可以應用在個人計算機上，從而使得個人也能擁有高性能的UNIX工作站。在研發國產OS的過程中，筆者對FreeBSD內核進行了深入研究和分析。本文描述了在FreeBSD I/O子系統上的研究工作。

1I/O系統的整體架構

FreeBSD I/O系統的層次劃分非常明確。用戶程序發出的I/O請求通過系統調用進入內核后，先后要經過虛擬文件系統層、具體文件系統層、GEOM層、ATA/CAM層，才能最終被硬件接收并處理（圖1）。I/O操作的執行過程，實際就是I/O請求從上到下層層發送的過程。在不同層次I/O請求的數據結構分別為uio->buf->bio->ata_request。

1．1虛擬文件系統層（VFS）

現代操作系統大都支持多種文件系統。要實現這個目的，就要將對各種不同文件系統的操作和管理納入到一個統一的框架中，讓內核中的文件系統界面成為一條文件系統總線，而具體文件系統成為連接在其上的插槽。用戶程序可以通過同一個文件系統操作界面，即一組系統調用，對各種不同的文件系統（以及文件）進行操作。因此，虛擬文件系統為用戶程序提供統一、抽象、虛擬的文件系統界面，隱去了各種不同文件系統的實現細節[1]。對于具體文件系統來說，VFS 是一個管理者，而對內核其他子系統來說，VFS 是它們與具體文件系統的一個接口。

VFS 的作用主要有：

（1）對具體文件系統的數據結構進行抽象，以一種統一的數據結構進行管理；

（2）接收用戶層的系統調用，如write、open、stat、link等；

（3）支持多種具體文件系統之間的相互訪問；

（4）接收內核其他子系統，特別是內存管理子系統的操作請求。

每個文件在虛擬文件系統層由一個vnode數據結構代表，它是文件系統的最高層抽象。Vnode向具體的文件系統提供統一接口，在FreeBSD中實際上就是一個函數指針的數組（由具體文件系統提供的相應函數）。一個具體文件系統想要被FreeBSD 支持，必須按照這個接口編寫自己的操作函數，將自己的細節對內核其他子系統隱藏起來。實際上，要支持一個新的文件系統，主要任務就是編寫這些接口函數。

1．2具體文件系統層

在FreeBSD中使用默認的UFS1（UFS2）文件系統，它們起源于Berkeley的FFS（Fast File System），是UFS(UNIX File System)文件系統的兩個主要變種（實際上，在FreeBSD中，UFS是與FFS結合起來實現的）。在5．0版本以前，FreeBSD的默認文件系統是UFS1，在5.x和6.0中，默認文件系統都是UFS2。UFS2比UFS1增加了對大文件、大硬盤的支持[2]。下面在提到UFS時，如無特殊說明，統指這兩種文件系統。

先說明一下inode結構。1．1節中提到的vnode結構是在VFS層使用的。對于每種文件系統來說，它們應該有自己的索引節點（或類似結構），在UFS/FFS文件系統中，這種索引結構就是inode了。其中包括如inode號、文件大小以及一些與鏈接或目錄相關的信息等。

不同的文件系統在初始化時，應該以不同的函數指針調用getnewvnode，以此設置自己專有的操作，如：

error=getnewvnode(\"ufs\"， mp， ffs_vnodeop_p， vp);

error=getnewvnode(\"devfs\"， mp， devfs_vnodeop_p， vp);

error=getnewvnode(\"none\"， (struct mount *)0， spec_vnodeop_p， nvp);

而在getnewvnode()函數中，會把1．1節中提到的接口（函數指針數組）設置為傳遞過來的參數，這就完成了VFS對具體文件系統的鏈接。值得注意的是，在UFS初始化時，所使用的函數轉換指針是ffs_vnodeop_p，而不是ufs_vnodeop_p。通過它們及相關代碼可以看到，ffs_vnodeop_p的第一項，也就是默認處理函數，是指向ufs_vnoperate()函數；凡是ffs_vnodeop_p中沒有定義的函數，都會調用ufs_vnodeop_p中的對應函數指針來處理?？梢娫贔reeBSD中，FFS和UFS的實現是緊密結合的，這主要是為了盡量多地復用代碼。

在這里必須對SPECFS進行說明。在FreeBSD中，SPECFS文件系統是普通文件系統節點和設備節點的紐帶，它承上啟下于UFS和I/O系統的下一個層次——GEOM層。在UFS層的操作完成后，需要向下層發送I/O請求時，必須使用inode數據結構中的i_devvp找到該inode所在的設備（這里所說的設備，并不是真正的物理設備，而是由GEOM所管理的虛擬設備）節點，然后通過SPECFS中實現的VFS接口（主要是spec_xstrategy()函數）將該I/O請求向下發送。

1．3GEOM層

GEOM是FreeBSD中磁盤I/O的模塊化管理框架[3]。從文件系統向設備發送的所有I/O請求都必須經過GEOM，由GEOM選擇相應的設備并將這些請求（可以作一定的轉換）發送給設備驅動。只要遵循GEOM的編程接口和規定，系統設計人員能以模塊形式實現符合自己要求的任意磁盤I/O轉換，而這些轉換對于上層文件系統和下層硬件驅動來說都是透明的。GEOM框架有點類似于以前的邏輯卷管理程序vinum（它在FreeBSD中仍然存在，但是由于GEOM的出現，其使用正在減少。vinum的發展趨勢是向GEOM靠攏），但是功能更為強大、可擴展性更強、更為靈活。目前，FreeBSD發行版中提供的特殊轉換包括跨文件系統管理、mirror、raid3、數據加密、壓縮存儲。對于不需要進行特殊處理的場景，如對于一般的文件讀寫，在經過GEOM層時基本上只要原樣向下面設備層發送就可以了（僅需將請求轉換成較低層次的數據結構）。

GEOM中重要的概念包括：

（1）class

GEOM中，每一類型的I/O轉換被稱為一種class，它在內核中對應的數據結構是g_class。其定義了該轉換類型的名稱（如“Mirror”）、版本，更重要的是在其中定義了許多函數指針，包括系統啟動時的自檢函數（config）、初始化函數（init）、轉換實例的撤銷函數（destroy_geom）、I/O請求的開始函數（start）等。目前已實現轉換，它們在內核中都有對應的g_class類型的變量，如g_bde_class、g_raid3_class等。

（2）geom

GEOM借鑒了面向對象的概念，一種I/O轉換類型可以對應于多個轉換實例（每個實例對應一個或一組相關的設備）。也就是說，在同一臺機器中可以對不同的設備定義類似的轉換（如兩個磁盤都需要加密，但是它們的加密參數、磁盤特性可以不同）。這些轉換實例稱為geom，對應的數據結構是g_geom。g_geom中也定義了與具體轉換有關的函數，它們大都與g_class中的函數相同，是在geom創建時從class中繼承下來的。I/O請求涉及的具體設備均對應一個geom，該geom管理并轉換與這個具體設備對應的I/O請求。當然，class和geom的關系，如果是用面向對象語言來實現就更容易理解。

弄清楚class和geom后，另外兩個重要概念provider和consumer就更容易理解一些。

在GEOM的處理過程中，I/O請求可以經過數次轉換，所有的轉換對于文件系統或設備來說都是透明的。因此，可以將經歷的這些轉換看成是GEOM的小層次。那么，在這些小的層次之間，上層geom和下層geom之間又是如何聯系的呢？

（3）provider

在這些小層次中，下層的geom會提供一個或多個provi－der。如果其他geom要向該geom發送I/O請求，就必須先連接到這個geom的某一個provider上，然后才能通過這個provider將I/O請求傳遞給下層的geom。如果把下層的geom比做服務提供商，provider就可以認為是這個公司的前臺?？蛻粼谙蛟摴菊埱蠓諘r，必須到前臺登記，由前臺再將它們的請求發送到后面的生產車間去。一個公司可能會提供多種服務，每種服務可以由一個前臺負責受理，這也就是一個geom可以有多個provider的原因。provider相應的數據結構是g_provider。

（4）consumer

上層geom與下層geom的provider聯系時，也有一個代理人，即consumer。一個geom可以有多個consumer，它們負責與不同合作公司的provider聯系。

Consumer和provider的關系是多對一的。因為一個geom如果需要與別的provider聯系，它可以使用別的consumer來代理，而不必使用同一個consumer來回切換；而下層的geom不知道（也無須知道）會有多少geom要求自己提供服務（I/O請求的轉換）。因此provider被設計成允許與多個consumer通信。

磁盤分區的管理也與GEOM密切相關，從邏輯盤到物理盤的對應關系也可以看成是I/O請求的轉換。它主要分為三個子層次：①disk層對應于物理硬盤。I/O請求再往下發送的話，就脫離GEOM，進入設備層了。②mbr層對應于安裝FreeBSD時partition的選擇和設置（這里的mbr并非通常所指的主引導扇區）。③bsd層對應于FreeBSD安裝時label的選擇和設置。這三者的關系如圖2所示。

1．4磁盤子系統層(CAM/ATA層)

磁盤子系統主要包括CAM（Common Access Method）和ATA（Advanced Technology Attachment），它們直接與底層硬件打交道。磁盤子系統將I/O請求發送給磁盤控制器后，內核的工作就到此為止。下面由磁盤控制器控制磁頭的移動、磁盤數據的讀入/寫出。硬件工作完成后，控制器發出中斷請求，CPU捕獲中斷請求后將控制權交給中斷處理函數（由磁盤子系統在初始化時注冊），它從磁盤控制器獲取當前狀態并在適當時候把I/O結果返回給上層。

早先的FreeBSD中有多種磁盤子系統。其中大多數已在發展過程中被納入到CAM中，如SPI、光纖通道、Umass、IEEE 1394、ATAPI等。但是，采用ATA接口的磁盤系統要求細粒度的加鎖機制，CAM目前還不能提供，因此它被單獨實現，主要用來支持ATA接口的硬盤、光盤、磁帶等。

第2章的分析是以對ATA硬盤的操作為例，把ATA子系統最重要的數據結構簡要介紹一下。在ATA層中，ata_channel結構是ATA通道（如系統的主從IDE接口各自對應一個ATA通道）的描述；ata_device結構是ATA設備的描述，多個ATA設備可以共用同一個ATA通道（如系統的主IDE接口中可以連接兩塊ATA硬盤），它是各種ATA設備的通用抽象；最后，ATA硬盤是由ad_softc結構來表示的。

2Read情景分析

本章以讀取硬盤數據作為一個典型的輸入/輸出情景。從系統調用read開始，到底層驅動向設備發送啟動命令，到硬件完成數據讀入后的處理，本文將對這個過程進行詳細分析，從而顯示FreeBSD中I/O系統的基本工作流程。對于其他I/O請求，所經歷的過程是類似的。

2．1I/O請求結構體

I/O系統的四個層次中，用來描述I/O請求的數據結構分別為uio、buf、bio、ata_request（下面將以ATA硬盤為例，因此不涉及SCSI硬盤中I/O請求對應的數據結構），它們恰當地描述了各自層次的I/O屬性。例如，uio根據系統調用的參數設置了文件中的相對位移，用于存放讀入數據的緩沖區等，這主要體現了應用程序的要求。再如，由于文件系統總是將設備數據分塊（Block）管理，在將I/O請求發送到具體文件系統層時，要根據其參數將文件位移轉換成塊號和塊內地址。buf結構中即定義了相應成員。

2．2流程分析

假設某應用程序發出了read系統調用，嘗試讀取磁盤上的文件（設文件系統為UFS）。這一情景的詳細執行流程（在分析過程中只列出了一些重要函數，實際的函數調用關系更為復雜），可以分為以下七個階段：

（1）發送I/O請求到GEOM層的隊列中，進程休眠等待數據讀入。

發出read()系統調用

read()→vn_read()

打開文件對應的vnode；通過虛擬文件層的接口將I/O請求（uio結構體）發送給具體文件系統的處理函數（這里是ffs_read()）。

ffs_read()→breadn()

breadn()等函數計算數據所在的block，將uio結構體轉換成buf結構體；spec_specstrategy()函數將buf發送給dev_strategy()。

dev_strategy()→g_dev_strategy()：

dev_strategy()函數計算數據在邏輯設備上的地址，將buf結構體轉換成bio結構體；g_dev_strategy()函數將I/O請求（bio結構體）發送到g_bio_run_down隊列中。此后，進程返回到breadn()中，調用bufwait()函數后進入休眠，直到I/O完成后被喚醒（見下面對步驟（7）的分析）。

（2）g_down線程從隊列中取出I/O請求，經過bsd、mbr、disk三個GEOM子層次（在這三個子層次中，只需要簡單地變換一下邏輯地址即可）后向設備層發送。

g_io_schedule_down()函數

該函數以線程的形式被調度運行，處理g_bio_run_down中的I/O請求，依次將這些請求發送給涉及的geom（調用相應geom的start函數）。

FreeBSD的磁盤管理包括bsd、mbr、disk三個層次，前兩者對應的start函數都是g_slice_start()，而disk對應的start函數是g_disk_start()。由于I/O請求是bsd→mbr→disk，正常情況下，每個I/O請求要進出g_bio_run_down隊列三次。前兩次出隊被g_slice_start()處理，第三次被g_disk_start()處理。

g_io_schedule_down()→g_slice_start()

g_slice_start()的作用是將I/O請求向下一個子層（mbr子層或disk子層）發送。

g_io_schedule_down()→g_disk_start()

g_disk_start()將I/O請求發送到設備層。由于這里只關心ATA硬盤，這次I/O請求的接收函數是adstrategy()。

（3）設備驅動將I/O請求發送給磁盤控制器。

adstrategy()→ata_generic_command()

在該階段中，首先需要把上層傳入的I/O請求（bio結構體）轉換為能夠描述ATA硬盤參數的ata_request；然后按照它們所在的位置進行排序，插入到ATA通道的I/O請求隊列中；接著，ata_start()從ATA通道的隊列中取出下一個待處理的I/O請求，調用ata_begin_transaction()對磁盤的I/O控制器發送DMA傳輸命令。

（4）磁盤控制器從硬盤上讀入數據。

硬件操作……

（5）DMA完成，此時數據已經讀入到內核中。將處理結果向GEOM層發送。這一階段處于中斷上下文中，操作不能過于復雜，以確保不影響系統的性能。

ata_interrupt()函數

磁盤從指定的扇區讀入數據后，向CPU發送中斷請求，CPU進入本函數進行中斷處理，它讀取磁盤控制器的寄存器狀態后調用下面的函數。

ata_end_transaction()函數

該函數在重置磁盤控制器狀態（以便下次DMA操作）后，將結果記錄在當前處理的I/O請求（ata_request結構體）中。

ata_finish()函數

將處理完成的I/O請求（ata_request結構體）進行轉換（上層所需的bio結構體），然后調用bio_taskqueue()函數將之返回給GEOM層。與步驟（1）不同的是，這里將bio插入到了g_bio_run_task隊列中。

（6）g_up線程從隊列中取出I/O請求（bio結構體），經過disk、mbr、bsd三個子層次的反向轉換后向文件系統發送。這與步驟（2）相對應，并且過程也很類似。

g_io_schedule_up()函數

該函數也是以線程的方式被調度運行。它的作用是處理g_bio_run_task和g_bio_run_up兩個隊列中的I/O請求。從設備層返回的I/O請求被加入到前者中，實際處理函數是ata_completed()；而后者用于I/O請求在GEOM中各個子層間的傳遞，實際處理函數是biodone()。

ata_completed()→biodone()

在biodone()中，調用bio結構體的相應函數（bio_done函數指針）對I/O請求進行逆向轉換。在各子層次中，該函數指針被賦值為不同的函數，包括g_disk_done、g_std_done、g_dev_done、bufdonebio等。按照次序，這里應該執行g_disk_done，這樣又回到了GEOM的disk子層。

g_io_schedule_up()→g_disk_done()

與g_disk_start()相對應，g_disk_done()的作用是將完成的I/O請求（bio結構體）向mbr子層發送。與步驟（2）相類似，這里將bio插入到g_bio_run_up隊列中，在合適的時候再由g_up線程取出進行處理。

g_io_schedule_up()→g_std_done()

g_std_done()函數與g_slice_start()相對應，并且處理方式也類似，只不過是將bio向上傳遞。I/O請求會第二次經由g_up線程的調度而進入g_std_done()，不過處理對象變成了bsd子層中的bio。此后它會第三次入隊，交由g_up線程處理。

g_io_schedule_up()→g_dev_done()

g_dev_done()函數與g_dev_strategy()相對應，它會間接調用bufdonebio()函數。

bufdonebio()函數

該函數與dev_strategy()相對應。函數里面，最重要的是用原來的文件系統層的I/O請求（buf結構體）調用bufdone()函數。下面，就回到了文件系統層。

（7）喚醒正在等待數據而休眠的用戶進程。與步驟（1）對應。

bufdone()函數：

在對步驟（1）的分析中提到，I/O請求在向下發送到GEOM層，被插入到g_bio_run_down隊列中后就返回到breadn()函數，而以后的操作由g_down線程啟動，具體什么時候能執行完成是不確定的（受系統調度和磁盤狀態的影響）。因此，在breadn()中會調用bufwait()進入睡眠狀態，等待I/O操作的完成。當操作結束，I/O請求從下面返回到bufdone()時，會通知睡眠中的原進程，數據已經得到，可以繼續執行了。此后，breadn()向上一層一層地返回，到達ffs_read()時會將數據拷貝到用戶空間中的指定位置（假設這個情景是由系統調用發起）。這樣，一次從用戶程序發起的read請求就基本結束了。

3FreeBSD I/O系統性能分析

本文使用Bonnie++[4]對FreeBSD 5.4的I/O系統進行性能評測，并與Linux 2．6．11進行橫向比較。評測和比較結果如表1所示。

注：重寫即從文件中讀入數據并修改之，然后再寫回文件。主要用于測試I/O系統的緩存性能。

評測機器使用普通IDE硬盤?？梢钥吹剑現reeBSD在以塊方式讀寫數據時明顯優于Linux，在以字節方式讀寫時則有所不如，而前者在實際應用中占絕大多數。在創建文件方面，FreeBSD的I/O系統也具有較大優勢；其余評測項的結果則基本相當。因此筆者認為，FreeBSD的I/O系統不僅具有層次清晰、擴展靈活的優點，它的性能也非常優異。

4結束語

FreeBSD的穩定性和優異性能使得它成為支持許多關鍵領域和應用的操作系統。深入分析其內核設計和實現，掌握其中的關鍵技術是筆者的研究目的之一。通過源碼分析，本文描述了其I/O子系統的整體框架、算法，并對其性能進行了評測分析。在此基礎上，筆者計劃利用GEOM層的特殊I/O轉換實現一個加入了新的安全機制的文件系統。

參考文獻：

[1]毛德操，胡希明.Linux內核源代碼情景分析[M].杭州:浙江大學出版社，2001:415－417.

[2]CARRIER B.File system forensic analysis[M]. Boston: Addison Wesley Professional， 2005:501.

[3]McKUSICK M K， NEVILLE－NEIL G V. The design and implementation of the FreeBSD operating system[M]. Boston: Addison Wesley Professional， 2004:359.

[4]COKER R. Bonnie++ 1.03a[EB/OL].[2006].http://www.coker.com.au/bonnie++/.

[5]FreeBSD 系統結構手冊[EB/OL].[2006－03－22].http://cnsnap.cn.freebsd.org/doc/zh_CN.GB2312/books/arch－handbook/.

[6]FreeBSD handbook[EB/OL].[2006－03－22].http://www.freebsd.org/doc/en_US.ISO8859－1/books/handbook/index.htm.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”