Page cache和Buffer cache[轉1]

Page cache實際上是針對檔案系統的，是檔案的緩衝，在檔案層面上的資料會緩衝到page cache。檔案的邏輯層需要映射到實際的物理磁碟，這種映射關係由檔案系統來完成。當page cache的資料需要重新整理時，page cache中的資料交給buffer cache，但是這種處理在2.6版本的核心之後就變的很簡單了，沒有真正意義上的cache操作。

在Linux 2.6的核心中Page cache和Buffer cache進一步結合，Buffer pages其實也是Page cache裡面的頁。從Linux演算法實現的角度，Page cache和Buffer cache目前是一樣的,只是多了一層抽象，通過buffer_head來進行一些訪問管理。可以理解為只有Page cache概念亦可。在Linux 2.6的核心中Page cache和Buffer cache進一步結合，Buffer pages其實也是Page cache裡面的頁。從Linux演算法實現的角度，Page cache和Buffer cache目前是一樣的,只是多了一層抽象，通過buffer_head來進行一些訪問管理。可以理解為只有Page cache概念亦可。

標準IO：

在 Linux 中，這種訪問檔案的方式是通過兩個系統調用實現的：read() 和 write()。當應用程式調用 read() 系統調用讀取一塊資料的時候，如果該塊資料已經在記憶體中了，那麼就直接從記憶體中讀出該資料並返回給應用程式；如果該塊資料不在記憶體中，那麼資料會被從磁碟上讀到頁高緩衝中去，然後再從頁緩衝中拷貝到使用者地址空間中去。如果一個進程讀取某個檔案，那麼其他進程就都不可以讀取或者更改該檔案；對於寫資料操作來說，當一個進程調用了 write() 系統調用往某個檔案中寫資料的時候，資料會先從使用者地址空間拷貝到作業系統核心地址空間的頁緩衝中去，然後才被寫到磁碟上。但是對於這種標準的訪問檔案的方式來說，在資料被寫到頁緩衝中的時候，write() 系統調用就算執行完成，並不會等資料完全寫入到磁碟上。Linux 在這裡採用的是我們前邊提到的延遲寫機制（ deferred writes ）。如果使用者採用的是延遲寫機制（ deferred writes ），那麼應用程式就完全不需要等到資料全部被寫回到磁碟，資料只要被寫到頁緩衝中去就可以了。在延遲寫機制的情況下，作業系統會定期地將放在頁緩衝中的資料刷到磁碟上。

直接IO：

凡是通過直接 I/O 方式進行資料轉送，資料均直接在使用者地址空間的緩衝區和磁碟之間直接進行傳輸，完全不需要頁緩衝的支援。作業系統層提供的緩衝往往會使應用程式在讀寫資料的時候獲得更好的效能，但是對於某些特殊的應用程式，比如說資料庫管理系統這類應用，他們更傾向於選擇他們自己的緩衝機制，因為資料庫管理系統往往比作業系統更瞭解資料庫中存放的資料，資料庫管理系統可以提供一種更加有效緩衝機制來提高資料庫中資料的存取效能。

簡單說來，page cache用來快取檔案資料，buffer cache用來緩衝磁碟資料。在有檔案系統的情況下，對檔案操作，那麼資料會緩衝到page cache，如果直接採用dd等工具對磁碟進行讀寫，那麼資料會緩衝到buffer cache。

補充一點，在檔案系統層每個裝置都會分配一個def_blk_ops的檔案操作方法，這是裝置的操作方法，在每個裝置的inode下面會存在一個radix tree，這個radix tree下面將會放置快取資料的page頁。這個page的數量將會在top程式的buffer一欄中顯示。如果裝置做了檔案系統，那麼會產生一個inode，這個inode會分配ext3_ops之類的操作方法，這些方法是檔案系統的方法，在這個inode下面同樣存在一個radix tree，這裡會快取檔案的page頁，快取頁面的數量在top程式的cache一欄進行統計。從上面的分析可以看出，2.6核心中的buffer cache和page cache在處理上是保持一致的，但是存在概念上的差別，page cache針對檔案的cache，buffer是針對磁碟塊資料的cache，僅此而已。

"如果一個進程讀取某個檔案，那麼其他進程就都不可以讀取或者更改該檔案；" 對這一句話存在質疑。

原文

http://blog.chinaunix.net/uid-1829236-id-3152172.html