函數(shù)block_read_full_page( )的具體實現(xiàn)過程如圖2所示。系統(tǒng)根據(jù)傳入的參數(shù)，獲得Block大小，生成相應的緩存空間，然后反復發(fā)出Block讀的Request，直到完成整個Page的讀任務。

如圖2所示Block_read_full_page( )的實現(xiàn)機理中，最重要的是根據(jù)系統(tǒng)狀況，經(jīng)過計算確切地獲得將由多少個Block來組成一個Page。

在Linux實現(xiàn)中，Block大小決定于文件描述符inode中的i_blkbits域。在Linux中的FAT32文件系統(tǒng)設計中，inode->i_blkbits是由FAT32系統(tǒng)中的logic_sector_size決定的，即用/linux-2.4.x/fs/fat/inode.c來實現(xiàn)從FAT32文件系統(tǒng)映射到Linux的inode各項定義。

1.5 系統(tǒng)MAKE_REQUEST[1-4]

經(jīng)過上述各個步驟的計算，在文件系統(tǒng)實現(xiàn)中，將文件讀操作轉(zhuǎn)化為若干個不同的Block讀需求，最后向下層驅(qū)動程序?qū)影l(fā)起具體的命令Request。上述的轉(zhuǎn)化，基本上是根據(jù)底層配置以及內(nèi)存管理的需求，將大的/整體的命令細分/拆分為更加細小的動作。

而在實際執(zhí)行過程中，肯定存在較多的過度拆分的情況，以致于產(chǎn)生過多低效率的命令，因此，在具體實現(xiàn)過程中，為了避免這種情況，在實際發(fā)出Request之前，需要對其進行相應的檢查，合并相關的Request，以提高系統(tǒng)實現(xiàn)性能。這個過程將由submit_bh來完成。

圖3所示是submit_bh函數(shù)中的主體調(diào)用子函數(shù)_make_request的實現(xiàn)過程。在FAT32實現(xiàn)中，_make_request根據(jù)獲得的Block大小、存儲設備的sector number，準備好內(nèi)存空間后，向IDE發(fā)出具體的Request。而具體的Request合并將發(fā)生在發(fā)出Request之前。其實現(xiàn)原理根據(jù)當前隊列中Request的地址相關性來判斷。

2 優(yōu)化策略分析

面對提高文件系統(tǒng)訪問性能的需求，經(jīng)過分析系統(tǒng)如何處理用戶發(fā)起的讀命令，觀察read( )命令從VFS到具體的文件系統(tǒng)FAT32的實現(xiàn)，轉(zhuǎn)化為具體的每一個Request的整個過程，系統(tǒng)的優(yōu)化可從以下幾個方面進行。

2.1 Block讀操作改進

根據(jù)1.4節(jié)針對block_read_full_page( )的描述，實際上是根據(jù)實際文件系統(tǒng)定義的Block大小，將一個page轉(zhuǎn)化為多個Block的讀動作。而在FAT32的具體實現(xiàn)中，根據(jù)/linux-2.4.x/fs/fat/inode.c文件中的描述，Block size等于logic_sector_size的大小，即邏輯扇區(qū)大小。

在FAT文件系統(tǒng)的定義中，邏輯扇區(qū)是為了統(tǒng)一不同硬盤的物理扇區(qū)而設置的。由于一般物理扇區(qū)最小為512B，因此在FAT32普遍實現(xiàn)中，邏輯扇區(qū)設置為512B。

而當前大容量的硬盤系統(tǒng)，其物理扇區(qū)普遍大于4KB。在這種情形下，根據(jù)Linux上的FAT32實現(xiàn)，一個4KB或者以上的物理扇區(qū)的讀，被人為地劃分為8次512B邏輯扇區(qū)的讀命令。而由于物理原因，可知道物理扇區(qū)將是磁盤上最小的尋址單位，也就是說，在最壞的情況下（即下層__make_request沒有及時判斷出這些buffer是可以合并的），向一個以4KB為扇區(qū)的硬盤發(fā)出一個page（4KB）的讀命令，最后將由8次同一個扇區(qū)的讀動作來實現(xiàn)。

針對block_read_full_page劃分的不合理，可以嘗試用重寫block_read_full_page來實現(xiàn)，即擴大Block為4KB。這樣即可以認為，一個Linux的page讀將按照一次Block讀來完成。同時由于Linux內(nèi)存管理都以4KB大小的page作為基本單位，這樣在所有文件系統(tǒng)的內(nèi)部，將以4KB為最小單位進行讀取，把跨4KB的特殊情況留給下層驅(qū)動來完成拆分（由于大容量硬盤的應用目標，這種情況幾乎不會出現(xiàn)）。因此，Block改進就是通過改進Block的大小，進行合并過多的拆分，來達到提高系統(tǒng)的讀性能的作用。

2．2 預讀機制控制

Linux系統(tǒng)上的FAT32文件系統(tǒng)實現(xiàn)，依然強烈依賴著預讀機制來完成實際的讀操作。這是由于Linux最初是以PC機為設計目標的，即存在內(nèi)存交換文件和各種緩沖機制來對有限的資源進行無限的邏輯擴展[5]。
這種多重緩沖的設計機制，非常適合應用程序/控制命令流存儲的磁盤管理。然而，在本嵌入式系統(tǒng)設計中，F(xiàn)AT32作為數(shù)據(jù)存儲空間，數(shù)據(jù)存儲相對有序，并且可預測性比較強。因此，這種抽象帶來的好處不是特別的明顯。同時由于存在多級緩沖，尤其是硬盤系統(tǒng)的多級緩沖，會造成以下幾個缺點：

(1)因多次數(shù)據(jù)搬移，造成性能下降。對于嵌入式系統(tǒng)尤其是消費類設備，由于成本的原因，其總線帶寬（包括內(nèi)存總線與外部總線）都是相對有限的，因此，在這類總線中的數(shù)據(jù)搬移造成的延遲，是不能忽略的(而PC機的設計中，由于高速的內(nèi)存吞吐量，往往這個延遲是可以忽略的)。

(2)緩沖和cache的存在，會造成具體動作更多不可預測性，這違反了實時系統(tǒng)的需求。因為嵌入式系統(tǒng)很多層面都有一定的實時性要求；其次，增加了硬盤電源管理的難度，即硬盤狀態(tài)將頻繁切換，減少有機會進入省電的Idle模式及更加省電的Sleep模式，浪費了硬盤自身APM（Advanced Power Management）帶來的好處。
因此，在本設計中需要對預讀機制進行管理，甚至去除預讀機制。實際上是對文件讀實現(xiàn)中的do_generic_file_read( )函數(shù)進行改造，去除了預讀判斷機制，采用直接調(diào)用方式。

2．3 Page機制改進

整個文件系統(tǒng)的讀操作，將以page為單位進行相應的規(guī)劃，即以4 096B為考慮對象。而在真實的磁盤系統(tǒng)中，由于大容量磁盤的普及，4 096B幾乎成了最小的物理扇區(qū)。面對這樣的磁盤系統(tǒng)，其FAT文件讀寫具體實現(xiàn)，實際上不能充分利用底層硬件以及驅(qū)動程序提供的各種優(yōu)化措施，如DMA等[6-7]。

針對這樣的思路，需要引入多個page讀操作的相關性，即在fat_readpage( )之前增加多個page合并的判斷。可以借鑒Request合并的方式進行page合并，即通過目標地址判斷的方式進行合并部分Page讀動作。

3 優(yōu)化實例

在實際優(yōu)化中，采用了前面提到的三種優(yōu)化策略,在某一個實際的系統(tǒng)上進行相應的測試，取得了較好的效果。
圖4是一個ARM嵌入式系統(tǒng)的詳細測試結果。該測試的物理實施條件是：

ARM7TDMI的系統(tǒng)，CPU頻率88MHz，8KB i-cache/no d-cache；硬盤掛接的EMIF為44MHz，16bit位寬；SDRAM為32bit位寬，運行在88MHz下；硬盤為4 200轉(zhuǎn)，20GB；系統(tǒng)采用μCLinux 2.4.18。

測試采用發(fā)起read( )用戶讀操作進行相應的測試。其中每個測試采用不同大小的buffer來觀察實際優(yōu)化前/后的訪問速率比較。

從測試結果可以看出，在采用buffer為8KB進行文件讀時，可以取得超過50%以上的訪問性能的提升。同時在這種測試條件下，也獲得了最好的讀性能，達到2MB/s以上的測試性能。這個讀性能基本上已可以滿足很多多媒體系統(tǒng)所需要的數(shù)據(jù)流要求。

同時在這種優(yōu)化策略下，應用系統(tǒng)可以有針對性地優(yōu)化應用程序中的各種讀操作。建議采用4KB或者8KB的buffer，使系統(tǒng)運行在最佳的狀態(tài)。

本文仔細分析了Linux的FAT32實現(xiàn)中讀操作的具體實現(xiàn)過程，針對FAT32系統(tǒng)實現(xiàn)的缺陷，提出了多種優(yōu)化策略，并在某一個嵌入式設備中進行具體的優(yōu)化和測試，取得了一定的性能提升。最后給出了對應用程序設計的建議。

文件系統(tǒng)優(yōu)化是一個非常深奧的課題，尤其是嵌入式系統(tǒng)的文件系統(tǒng)設計，針對不同的應用，應有不同的優(yōu)化目標。本文介紹了初步的優(yōu)化方法，在某一個具體的嵌入式設備上進行相應的實踐，取得了良好的效果。