read文件一個字節實際會發生多大的磁盤IO？

先講一個做者大約7年前我在某當時很火的一個應用分發創業公司的面試小插曲，該公司安排了一個剛工做1年多的一個同窗來面我，聊到咱們項目中的配置文件裏寫的一個開關，這位同窗就跳出來講，你這個讀文件啦，每一個用戶請求來了還得多一次的磁盤IO，性能確定差。藉由這個故事其實我發現了一個問題，雖然咱們中的大部分人都是計算機科班出身，代碼也寫的很遛。可是在一些看似司空見慣的問題上，咱們中的絕大多數人並無真正理解，或者理解的不夠透徹。

無論你用的是啥語言，C/PHP/GO、仍是Java，相信你們都有過讀取文件的經歷。咱們來思考兩個問題，若是咱們讀取文件中的一個字節：

• 是否會發生磁盤IO？
• 發生的話，Linux實際向磁盤讀取多少字節了呢？

爲了便於理解問題，咱們把c的代碼也列出來：

int main()  
{  	
	char    c;  
	int     in;

	in = open("in.txt", O_RDONLY); 
	read(in,&c,1);
	return 0;  
}

若是不是從事c/c++開發工做的同窗，這個問題想深度理解起來確實不那麼容易。由於目前經常使用的主流語言，PHP/Java/Go啥的封裝層次都比較高，把內核的不少細節都給屏蔽的比較完全。要想把上面的兩個問題搞的比較清楚，須要剖開Linux的內部來理解Linux的IO棧。

Linux IO棧簡介

廢話很少說，咱們直接把Linux IO棧的一個簡化版本畫出來：（官方的IO棧參考這個Linux.IO.stack_v1.0.pdf）

咱們在前面也分享了幾篇文章討論了上圖圖中的硬件層，還有文件系統模塊。但經過這個IO棧咱們發現，咱們對Linux文件的IO的理解仍是遠遠不夠，還有好幾個內核組件：IO引擎、VFS、PageCache、通用塊管理層、IO調度層等模塊咱們並無瞭解太多。彆着急，讓咱們一一道來：

IO引擎

咱們開發同窗想要讀寫文件的話，在lib庫層有不少種函數能夠選擇，好比read，write，mmap等。這事實上就是在選擇Linux提供的IO引擎。咱們最經常使用的read、write函數是屬於sync引擎，除了sync，還有map、psync、vsync、libaio、posixaio等。 sync，psync都屬於同步方式，libaio和posixaio屬於異步IO。

固然了IO引擎也須要VFS、通用塊層等更底層的支持才能實現。在sync引擎的read函數裏會進入VFS提供的read系統調用。

VFS虛擬文件系統

在內核層，第一個看到的是VFS。VFS誕生的思想是抽象一個通用的文件系統模型，對咱們開發人員或者是用戶提供一組通用的接口，讓咱們不用care具體文件系統的實現。VFS提供的核心數據結構有四個，它們定義在內核源代碼的include/linux/fs.h和include/linux/dcache.h中。

• superblock：Linux用來標註具體已安裝的文件系統的有關信息
• inode：Linux中的每個文件都有一個inode，你能夠把inode理解爲文件的身份證
• file：內存中的文件對象，用來保存進程和磁盤文件的對應關係
• desty：目錄項，是路徑中的一部分，全部的目錄項對象串起來就是一棵Linux下的目錄樹。

圍繞這這四個核心數據結構，VFS也都定義了一系列的操做方法。好比，inode的操做方法定義inode_operations(include/linux/fs.h)，在它的裏面定義了咱們很是熟悉的mkdir和rename等。

struct inode_operations {
				......
        int (*link) (struct dentry *,struct inode *,struct dentry *);
        int (*unlink) (struct inode *,struct dentry *);
        int (*mkdir) (struct inode *,struct dentry *,umode_t);
        int (*rmdir) (struct inode *,struct dentry *);
        int (*rename) (struct inode *, struct dentry *,
                        struct inode *, struct dentry *, unsigned int);
        ......

在file對應的操做方法file_operations裏面定義了咱們常用的read和write：

struct file_operations {
				......
        ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
        ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
				......
        int (*mmap) (struct file *, struct vm_area_struct *);
        int (*open) (struct inode *, struct file *);
        int (*flush) (struct file *, fl_owner_t id);

Page Cache

在VFS層往下看，咱們注意到了Page Cache。它的中文譯名叫頁高速緩存，是Linux內核使用的主要磁盤高速緩存，是一個純內存的工做組件，其做用就是來給訪問相對比較慢的磁盤來進行訪問加速。若是要訪問的文件block正好存在於Page Cache內，那麼並不會有實際的磁盤IO發生。若是不存在，那麼會申請一個新頁，發出缺頁中斷，而後用磁盤讀取到的block內容來填充它 ，下次直接使用。Linux內核使用搜索樹來高效管理大量的頁面。

若是你有特殊的需求想要繞開Page Cache，只要設置DIRECT_IO就能夠了。有兩種狀況須要繞開：

• 測試磁盤IO的真實性能
• 節約使用Page Cache時系統調用陷入到內核態，以及內核內存向用戶進程內存拷貝到開銷。

文件系統

在我在以前的文章《新建一個空文件佔用多少磁盤空間？》、《理解格式化原理》裏討論的都是具體的文件系統。文件系統裏最重要的兩個概念就是inode和block，這兩個咱們在以前的文章裏也都見過了。一個block是多大呢，這是運維在格式化的時候決定的，通常默認是4KB。

除了inode和block，每一個文件系統還會定義本身的實際操做函數。例如在ext4中定義的ext4_file_operations和ext4_file_inode_operations以下：

const struct file_operations ext4_file_operations = {
        .read_iter      = ext4_file_read_iter,
        .write_iter     = ext4_file_write_iter,
        .mmap           = ext4_file_mmap,
        .open           = ext4_file_open,
        ......
};

const struct inode_operations ext4_file_inode_operations = {
        .setattr        = ext4_setattr,
        .getattr        = ext4_file_getattr,
        ......
};

通用塊層

通用塊層是一個處理系統中全部塊設備IO請求的內核模塊。它定義了一個叫bio的數據結構來表示一次IO操做請求（include/linux/bio.h）。

那麼一次bio裏對應的IO大小單位是頁面，仍是扇區呢？都不是，是段！每一個bio可能會包含多個段。一個段是一個完整的頁面，或者是頁面的一部分，具體請參考https://www.ilinuxkernel.com/files/Linux.Generic.Block.Layer.pdf。

爲何要搞出個段這麼讓人費解的東西呢？這是由於在磁盤中連續存儲的數據，到了內存Page Cache裏的時候可能內存並不連續了。這種情況出現是正常的，不能說磁盤中連續的數據我在內存中就非得用連續的空間來緩存。段就是爲了能讓一次內存IO DMA到多「段」地址並不連續的內存中的。

一個常見的扇區/段/頁的大小對好比下圖：

IO調度層

當通用塊層把IO請求實際發出之後，並不必定會當即被執行。由於調度層會從全局出發，儘可能讓總體磁盤IO性能最大化。大體的工做方式是讓磁頭相似電梯那樣工做，先往一個方向走，到頭再回來，這樣磁盤效率會比較高一些。具體的算法有noop，deadline和cfg等。

在你的機器上，經過dmesg | grep -i scheduler來查看你的Linux支持的算法，並在測試的時候能夠選擇其中的一種。

讀文件過程

咱們已經把Linux IO棧裏的各個內核組件都介紹一邊了。如今咱們再從頭總體過一下讀取文件的過程

• lib裏的read函數首先進入系統調用sys_read
• 在sys_read再進入VFS裏的vfs_read、generic_file_read等函數
• 在vfs裏的generic_file_read會判斷是否緩存命中，命中則返回
• 若不命中內核在Page Cache裏分配一個新頁框，發出缺頁中斷，
• 內核向通用塊層發起塊I/O請求，塊設備屏蔽了磁盤、U盤的差別
• 通用塊層把用bio表明的I/O請求放到IO請求隊列中
• IO調度層經過電梯算法來調度隊列中的請求
• 驅動程序向磁盤控制器發出讀取命令控制，DMA方式直接填充到Page Cache中的新頁框
• 控制器發出中斷通知
• 內核將用戶須要的1個字節填充到用戶內存中
• 而後你的進程被喚醒

能夠看到，若是Page Cache命中的話，根本就沒有磁盤IO產生。因此，你們不要以爲代碼裏出現幾個讀寫文件的邏輯就以爲性能會慢的不行。操做系統已經替你優化了不少不少，內存級別的訪問延遲大約是ns級別的，比機械磁盤IO快了2-3個數量級。若是你的內存足夠大，或者你的文件被訪問的足夠頻繁，其實這時候的read操做極少有真正的磁盤IO發生。

咱們再看第二種狀況，若是Page Cache不命中的話，Linux實際進行了多少個字節的磁盤IO。整個IO過程當中涉及到了好幾個內核組件。 而每一個組件之間都是採用不一樣長度的塊來管理磁盤數據的。

• Page Cache是以頁爲單位的，Linux頁大小通常是4KB（避免有大神挑刺，這裏說下Linux能設置大內存頁）
• 文件系統是以塊爲單位來管理的。使用dumpe2fs能夠查看，通常一個塊默認是4KB
• 通用塊層是以段爲單位來處理磁盤IO請求的，一個段爲一個頁或者是頁的一部分
• IO調度程序經過DMA方式傳輸N個扇區到內存，扇區通常爲512字節
• 硬盤也是採用「扇區」的管理和傳輸數據的

能夠看到，雖然咱們從用戶角度確實是只讀了1個字節（開篇的代碼中咱們只給此次磁盤IO留了一個字節的緩存區）。可是在整個內核工做流中，最小的工做單位是磁盤的扇區，爲512字節，比1個字節要大的多。另外block、page cache等高層組件工做單位更大，因此實際一次磁盤讀取是不少字節一塊兒進行的。假設段就是一個內存頁的話，一次磁盤IO就是4KB（8個512字節的扇區）一塊兒進行讀取。

Linux內核中咱們沒有講到的是還有一套複雜的預讀取的策略。因此，在實踐中，可能比8更多的扇區來一塊兒被傳輸到內存中。

最後

操做系統的本意是作到讓你簡單可依賴， 讓你儘可能把它當成一個黑盒。你想要一個字節，它就給你一個字節，可是本身默默幹了許許多多的活兒。咱們雖然國內絕大多數開發都不是搞底層的，但若是你十分關注你的應用程序的性能，你應該明白操做系統的何時悄悄提升了你的性能，是怎麼來提升的。以便在未來某一個時候你的線上服務器扛不住快要掛掉的時候，你能迅速找出問題所在。

咱們再擴展一下，假如Page Cache沒有命中，那麼必定會有傳動到機械軸上的磁盤IO嗎？

其實也不必定，爲何，由於如今的磁盤自己就會帶一塊緩存。另外如今的服務器都會組建磁盤陣列，在磁盤陣列裏的核心硬件Raid卡里也會集成RAM做爲緩存。只有全部的緩存都不命中的時候，機械軸帶着磁頭纔會真正工做。

---

---

開發內功修煉之硬盤篇專輯：

• 1.磁盤開篇：扒開機械硬盤堅硬的外衣！
• 2.磁盤分區也是隱含了技術技巧的
• 3.咱們怎麼解決機械硬盤既慢又容易壞的問題？
• 4.拆解固態硬盤結構
• 5.新建一個空文件佔用多少磁盤空間？
• 6.只有1個字節的文件實際佔用多少磁盤空間
• 7.文件過多時ls命令爲何會卡住？
• 8.理解格式化原理
• 9.read文件一個字節實際會發生多大的磁盤IO？
• 10.write文件一個字節後什麼時候發起寫磁盤IO？
• 11.機械硬盤隨機IO慢的超乎你的想象
• 12.搭載固態硬盤的服務器究竟比搭機械硬盤快多少？

---

個人公衆號是「開發內功修煉」，在這裏我不是單純介紹技術理論，也不僅介紹實踐經驗。而是把理論與實踐結合起來，用實踐加深對理論的理解、用理論提升你的技術實踐能力。歡迎你來關注個人公衆號，也請分享給你的好友~~~