為了提高效率，略微複雜一些的作業系統對檔案的讀寫都是帶緩衝的，linux當然也不例外。所謂緩衝，就是作業系統為近期剛讀寫的檔案內容在核心保留乙份副本，以便當再次須要已經緩衝儲存在副本中的內容時就不必再暫時從裝置上讀入，而須要寫的時候則能夠先寫到副本中，待系統較為空暇的時候再從副本寫入裝置。在多程序的系統中，因為同乙個檔案可能為多個程序所共享，緩衝的作用就更為顯著。
然而，怎麼樣實現緩衝，在哪乙個層次上實現緩衝，確實乙個值得考慮的問題。
在檔案層有三種基本的資料結構:file、dentry、inode。
先看file結構:前面講過。乙個file結構代表著目標檔案的乙個上下文，不但不同的程序能夠在同乙個檔案上建立不同的上下文（每乙個程序都有自己的file結構體),就是同乙個程序也能夠通過開啟同乙個檔案多次而建立起多個上下文。假設在file結構中設定乙個緩衝區佇列，那麼緩衝區中的內容儘管貼近這個特定上下文的使用者，卻不便於為多個程序共享，甚至不便於同乙個程序開啟的不同上下文共享，這顯然是不合適的。
那麼dentry結構怎麼樣呢？這個資料結構並不屬於某乙個上下文，也不屬於乙個程序，能夠為全部程序和上下文共享。但是dentry結構與目標檔案並非一一相應的關係，通過檔案鏈結，我們能夠為已經存在的檔案建立別名。乙個dentry結構知識唯一的代表這檔案系統中的乙個節點，也就是乙個路徑名，但是多個節點能夠同一時候代表同乙個檔案，所以還應該再抽象一次。
但是，雖然以頁面為單位的緩衝對於檔案層確實是非常好的選擇，對於裝置層則不那麼合適了。對裝置層而言。最自然的當然是以記錄塊為單位的緩衝，由於裝置的讀寫都是以記錄塊為單位的。
只是，從磁碟上讀寫基本的時間都花在準備工作上，一旦準備好了以後讀乙個記錄塊與接連讀幾個記錄塊相差並不大，並且每次僅僅讀寫乙個記錄塊反而是不經濟的。所以每次讀寫若干連續的記錄塊、以頁面為單位緩衝並非問題。
還有一方面，假設以頁面為單位緩衝。而乙個頁面相當於若干連續記錄塊，那麼不管是對於緩衝頁面還是對於記錄塊緩衝區，其控制資訊顯然應該游離於該頁面之外，這些資訊不應該對映到程序的使用者空間。
這個問題不難解決。
在裝置層中要保持一些buffer_head結構。讓它們的b_data指標分別指向緩衝區頁面中的對應位置就能夠了。
以乙個緩衝頁面為例，在檔案層它通過乙個page資料結構掛入所屬inode結構的緩衝頁面佇列。並且同一時候又能夠通過各個程序的頁面對映表對映到這些程序的記憶體空間。而在裝置層又通過若干buffer_head結構掛入其所在裝置的緩衝區佇列。
在這樣乙個結構框架中，一旦所欲訪問的內容已經在緩衝頁面佇列中，讀檔案的效率就非常高了。僅僅要找到檔案的inode結構就找到了緩衝頁面的佇列，從佇列中找到對應的頁面就能夠讀出了。
上面的裝置緩衝區佇列我們還沒介紹是什麼東西，以下來介紹
當乙個塊調入記憶體時，它要儲存在乙個緩衝區中。每乙個緩衝區與乙個塊相應。它相當於是磁碟塊在記憶體中的表示，磁碟塊包括乙個或者多個扇區，可是不能超過乙個頁面。所以乙個物理頁能夠容納乙個或者多個記憶體中的塊。因為核心在處理資料時須要知道一些相關資訊（比方塊屬於哪乙個塊裝置。塊相應於哪個緩衝區等），所以每乙個緩衝區都有乙個相應的描寫敘述符。該描寫敘述符用buffer_head結構體表示。成為緩衝區頭，在檔案中定義，它包括了核心操作緩衝區的所有資訊。
事實上這個buffer_head存在於linux2.4版本號中。在linux中使用bio結構體取代。
HDFS檔案的讀寫操作理論解析
剛剛接觸hadoop，對於裡面的hdfs感覺思想就是分而治之再綜合的過程，不過這個分布式檔案系統還是蠻厲害的。現在介紹一下它的基本原理，通俗易懂。一 hdfs的一些基本概念 資料塊 block 大檔案會被分割成多個block進行儲存，block大小預設為64mb。每乙個block會在多個datano...
python理論9 檔案讀寫
想讀寫檔案首先要學會檔案路徑的規則。首先是關於斜槓 和 的問題 雖然有查到資料說推薦使用 windos下是 不過在pycharm裡實測都沒關係，甚至連個數也沒有限制，唯一要注意的是檔名要加字尾 例如txt,jpg等 否則無法識別。但是在命令提示符中windos下還是得用 open 將會返回乙個 fi...
檔案的讀寫
eg 文字中每一行的資料結構，它們是以tab鍵為間隔的 afghanistan baghlan 36.12 68.7 afghanistan balkh 36.758 66.896 include stdafx.h include fstream include using namespace st...