漫談linux檔案IO

來源:互聯網
上載者:User

 在Linux 開發中,有幾個關係到效能的東西,技術人員非常關註:進程,CPU,MEM,網路IO,磁碟IO。本篇檔案打算詳細全面,深入淺出。剖析檔案IO的細節。從多個角度探索如何提高IO效能。本文盡量用通俗易懂的視角去闡述。不copy核心代碼。

    闡述之前,要先有個大視角,讓我們站在萬米高空,鳥瞰我們的檔案IO,它們設計是分層的,分層有2個好處,一是架構清晰,二是解耦。讓我們看一下下面這張圖。

 

圖一

 

1.       穿越各層寫檔案方式

程式的最終目的是要把資料寫到磁碟上, 但是系統從通用性和效能角度,盡量提供一個折中的方案來保證這些。讓我們來看一個最常用的寫檔案典型example,也是路徑最長的IO。

{

         char *buf = malloc(MAX_BUF_SIZE);

    strncpy(buf, src, , MAX_BUF_SIZE);

    fwrite(buf, MAX_BUF_SIZE, 1, fp);

    fclose(fp);

}

這裡malloc的buf對於圖層中的application buffer,即應用程式的buffer;調用fwrite後,把資料從application buffer 拷貝到了 CLib buffer,即C庫標準IObuffer。fwrite返回後,資料還在CLib buffer,如果這時候進程core掉。這些資料會丟失。沒有寫到磁碟介質上。當調用fclose的時候,fclose調用會把這些資料重新整理到磁碟介質上。除了fclose方法外,還有一個主動重新整理操作fflush 函數,不過fflush函數只是把資料從CLib
buffer 拷貝到page  cache 中,並沒有重新整理到磁碟上,從page cache重新整理到磁碟上可以通過調用fsync函數完成。

 

從上面類子看到,一個常用的fwrite函數過程,基本上曆經千辛萬苦,資料經過多次copy,才到達目的地。有人心生疑問,這樣會提高效能嗎,反而會降低效能吧。這個問題先放一放。

 

有人說,我不想通過fwrite+fflush這樣組合,我想直接寫到page cache。這就是我們常見的檔案IO調用read/write函數。這些函數基本上是一個函數對應著一個系統調用,如sys_read/sys_write. 調用write函數,是直接通過系統調用把資料從應用程式層拷貝到核心層,從application buffer 拷貝到 page cache 中。

 

系統調用,write會觸發使用者態/核心態切換?是的。那有沒有辦法避免這些消耗。這時候該mmap出場了,mmap把page cache 地址空間映射到使用者空間,應用程式像操作應用程式層記憶體一樣,寫檔案。省去了系統調用開銷。

 

那如果繼續刨根問底,如果想繞過page cache,直接把資料送到磁碟裝置上怎麼辦。通過open檔案帶上O_DIRECT參數,這是write該檔案。就是直接寫到裝置上。

 

如果繼續較勁,直接寫扇區有沒有辦法。這就是所謂的RAW裝置寫,繞開了檔案系統,直接寫扇區,想fdsik,dd,cpio之類的工具就是這一類操作。

 

2.       IO調用鏈

列舉了上述各種穿透各種cache 層寫操作,可以看到系統提供的介面相當豐富,滿足你各種寫要求。下面通過講解圖一,瞭解一下檔案IO的調用鏈。

fwrite是系統提供的最上層介面,也是最常用的介面。它在使用者進程空間開闢一個buffer,將多次小資料量相鄰寫操作先緩衝起來,合并,最終調用write函數一次性寫入(或者將大塊資料分解多次write調用)。

Write函數通過調用系統調用介面,將資料從應用程式層copy到核心層,所以write會觸發核心態/使用者態切換。當資料到達page
cache後,核心並不會立即把資料往下傳遞。而是返回使用者空間。資料什麼時候寫入硬碟,有核心IO調度決定,所以write是一個非同步呼叫。這一點和read不同,read調用是先檢查page
cache裡面是否有資料,如果有,就取出來返回使用者,如果沒有,就同步傳遞下去並等待有資料,再返回使用者,所以read是一個同步過程。當然你也可以把write的非同步過程改成同步過程,就是在open檔案的時候帶上O_SYNC標記。

資料到了page cache後,核心有pdflush線程在不停的檢測髒頁,判斷是否要寫回到磁碟中。把需要寫回的頁提交到IO隊列——即IO調度隊列。又IO調度隊列調度策略調度何時寫回。

提到IO調度隊列,不得不提一下磁碟結構。這裡要講一下,磁頭和電梯一樣,盡量走到頭再回來,避免來回搶佔是跑,磁碟也是單向旋轉,不會反覆逆時針順時針轉的。從網上copy一個圖下來,具體這裡就不介紹。

IO隊列有2個主要任務。一是合并相鄰扇區的,而是排序。合并相信很容易理解,排序就是盡量按照磁碟選擇方向和磁頭前進方向排序。因為磁頭尋道時間是和昂貴的。

這裡IO隊列和我們常用的分析工具IOStat關係密切。IOStat中rrqm/s wrqm/s表示讀寫合并個數。avgqu-sz表示平均隊列長度。

核心中有多種IO調度演算法。當硬碟是SSD時候,沒有什麼磁軌磁頭,人家是隨機讀寫的,加上這些調度演算法反而畫蛇添足。OK,剛好有個調度演算法叫noop調度演算法,就是什麼都不錯(合并是做了)。剛好可以用來配置SSD硬碟的系統。

 

從IO隊列出來後,就到了驅動層(當然核心中有更多的細分層,這裡忽略掉),驅動層通過DMA,將資料寫入磁碟cache。

至於磁碟cache時候寫入磁碟介質,那是磁碟控制卡自己的事情。如果想要睡個安慰覺,確認要寫到磁碟介質上。就調用fsync函數吧。可以確定寫到磁碟上了。

 

3.       一致性和安全性

談完調用細節,再將一下一致性問題和安全問題。既然資料沒有到到磁碟介質前,可能處在不同的實體記憶體cache中,那麼如果出現進程死機,核心死,掉電這樣事件發生。資料會丟失嗎。

當進程死機後:只有資料還處在application cache或CLib
cache時候,資料會丟失。資料到了page cache。進程core掉,即使資料還沒有到硬碟。資料也不會丟失。

當核心core掉後,只要資料沒有到達disk cache,資料都會丟失。

掉電情況呢,哈哈,這時候神也救不了你,哭吧。

 

那麼一致性呢,如果兩個進程或線程同時寫,會寫亂嗎?或A進程寫,B進程讀,會寫髒嗎?

文章寫到這裡,寫得太長了,就舉出各種各樣的例子。講一下大概判斷原則吧。fwrite操作的buffer是在進程私人空間,兩個線程讀寫,肯定需要鎖保護的。如果進程,各有各的地址空間。是否要加鎖,看應用情境。

write操作如果寫大小小於PIPE_BUF(一般是4096),是原子操作,能保證兩個進程“AAA”,“BBB”寫操作,不會出現“ABAABB”這樣的資料交錯。O_APPEND 標誌能保證每次重新計算pos,寫到檔案尾的原子性。

資料到了核心層後,核心會加鎖,會保證一致性的。

 

4.       效能問題

效能從系統層面和裝置層面去分析;磁碟的物理特性從根本上決定了效能。IO的調度策略,系統調用也是致命殺手。

磁碟的尋道時間是相當的慢,平均尋道時間大概是在10ms,也就是是每秒只能100-200次尋道。

磁碟轉速也是影響效能的關鍵,目前最快15000rpm,大概就每秒500轉,滿打滿算,就讓磁頭不尋道,設想所有的資料連續存放在一個柱面上。大家可以算一下每秒最多可以讀多少資料。當然這個是理論值。一般情況下,碟片轉太快,磁頭感應跟不上,所以需要轉幾圈才能完全讀出磁軌內容。

另外裝置介面匯流排傳輸率是實際速率的上限。

另外有些等密度磁碟,磁碟外圍磁軌扇區多,線速度快,如果頻繁操作的資料放在外圍扇區,也能提高效能。

利用多磁碟並行作業,也不失為提高效能的手段。

 

這裡給個業界經驗值:機械硬碟順序寫~30MB,順序讀取速率一般~50MB好的可以達到100多M,
SSD讀達到~400MB,SSD寫效能和機械硬碟差不多。

 

Ps:

O_DIRECT  RAW裝置最根本的區別是O_DIRECT是基於檔案系統的,也就是在應用程式層來看,其操作對象是檔案控制代碼,核心和檔案層來看,其操作是基於inode和資料區塊,這些概念都是和ext2/3的檔案系統相關,寫到磁碟上最終是ext3檔案。 

RAW裝置寫是沒有檔案系統概念,操作的是扇區號,操作對象是扇區,寫出來的東西不一定是ext3檔案(如果按照ext3規則寫就是ext3檔案)。 

一般基於O_DIRECT來設計最佳化自己的檔案模組,是不滿系統的cache和調度策略,自己在應用程式層實現這些,來制定自己特有的業務特色檔案讀寫。但是寫出來的東西是ext3檔案,該磁碟卸下來,mount到其他任何linux系統上,都可以查看。 

而基於RAW裝置的設計系統,一般是不滿現有ext3的諸多缺陷,設計自己的檔案系統。自己設計檔案布局和索引方式。舉個極端例子:把整個磁碟做一個檔案來寫,不要索引。這樣沒有inode限制,沒有檔案大小限制,磁碟有多大,檔案就能多大。這樣的磁碟卸下來,mount到其他linux系統上,是無法識別其資料的。 

兩者都要通過驅動層讀寫;在系統引導啟動,還處於實模式的時候,可以通過bios介面讀寫raw裝置。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.