先講一個作者大約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）

file

我們在前面也分享了幾篇文章討論了上圖圖中的硬體層，還有檔案系統模塊，但通過這個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到多“段”地址并不連續的記憶體中的，

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

file

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作為快取，只有所有的快取都不命中的時候，機械軸帶著磁頭才會真正作業，

file

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

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

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/203302.html

標籤：其他

上一篇：010_初建工程

下一篇：020_idea顯示class檔案

read檔案一個位元組實際會發生多大的磁盤IO？

Linux IO堆疊簡介

IO引擎

VFS虛擬檔案系統

Page Cache

檔案系統

通用塊層

IO調度層

讀檔案程序

最后