Read 文件一個字節實際會發生多大的磁盤IO？
大家好，我是飛哥!
在日常開發中一些看似司空見慣的問題上，我覺得可能大多數人其實并沒有真正理解，或者理解的不夠透徹。不信我們來看以下一段簡單的讀取文件的代碼：
上圖中的代碼僅僅只是對某個文件讀取了一個字節，基于這個代碼片段我們來思考：
1、讀取文件 1 個字節是否會導致磁盤 IO ?
2、如果發生了磁盤 IO，那發生的是多大的 IO 呢?
大家平時用的各種語言 C++、PHP、Java、Go 啥的封裝層次都比較高，把很多細節都給屏蔽的比較徹底。如果想把上面的問題搞清楚，需要剖開 Linux 的內部來看 Linux 的 IO 棧。
一、大話 Linux IO 棧
廢話不多說，我畫了一個 Linux IO 棧的簡化版本。
通過 IO 棧可以看到，我們在應用層簡單的一次 read 而已，內核就需要 IO 引擎、VFS、PageCache、通用塊管理層、IO 調度層等許多個組件來進行復雜配合才能完成。
那這些組件都是干啥的呢?我們挨個簡單過一遍。不想看這個的同學可以直接跳到第二節的讀文件讀過程。
1.1 IO 引擎
開發同學想要讀寫文件的話，在 lib 庫層有很多套函數可以選擇，比如 read & write，pread & pwrite。這事實上就是在選擇 Linux 提供的 IO 引擎。
常見的 IO 引擎種類如下：
我們開篇中代碼片用的 read 函數就屬于 sync 引擎。IO 引擎仍然處于上層，它需要內核層的提供的系統調用、VFS、通用塊層等更底層組件的支持才能實現。
接著讓我們繼續深入到內核，來介紹各個內核組件。
1.2 系統調用
當進入到系統調用以后，也就進入到了內核層。
系統調用將內核中其它組件的功能進行封裝，然后通過接口的形式暴露給用戶進程來訪問。
對于我們的讀取文件的需求，系統調用需要依賴 VFS 內核組件。
1.3 VFS 虛擬文件系統
VFS 的思想就是在 Linux 上抽象一個通用的文件系統模型，對我們開發人員或者是用戶提供一組通用的接口，讓我們不用 care 具體文件系統的實現。VFS 提供的核心數據結構有四個，它們定義在內核源代碼的 include/linux/fs.h 和 include/linux/dcache.h 中。
superblock：Linux 用來標注具體已安裝的文件系統的有關信息。
inode：Linux 中的每一個文件/目錄都有一個 inode，記錄其權限、修改時間等信息。
desty：目錄項，是路徑中的一部分，所有的目錄項對象串起來就是一棵 Linux 下的目錄樹。
file：文件對象，用來和打開它的進程進行交互。
圍繞這這四個核心數據結構，VFS 也都定義了一系列的操作方法。比如，inode 的操作方法定義 inode_operations，在它的里面定義了我們非常熟悉的 mkdir 和 rename 等。對于 file 對象，定義了對應的操作方法 file_operations ，如下：
- // include/linux/fs.h
- struct file {
- ......
- const struct file_operations *f_op
- }
- 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);
- }
注意 VFS 是抽象的，所以它的 file_operations 里定義的 read、write 都只是函數指針， 實際中需要具體的文件系統來實現，例如 ext4 等等。
1.4 Page Cache
Page Cache。它的中文譯名叫頁高速緩存。它是 Linux 內核使用的主要磁盤高速緩存，是一個純內存的工作組件。Linux 內核使用搜索樹來高效管理大量的頁面。
有了它，Linux 就可以把一些磁盤上的文件數據保留在內存中，然后來給訪問相對比較慢的磁盤來進行訪問加速。
當用戶要訪問的文件的時候，如果要訪問的文件 block 正好存在于 Page Cache 內，那么 Page Cache 組件直接把數據從內核態拷貝到用戶進程的內存中就可以了。如果不存在，那么會申請一個新頁，發出缺頁中斷，然后用磁盤讀取到的 block 內容來填充它 ，下次直接使用。
看到這里，開篇的問題可能你就明白一半了，如果你要訪問的文件近期訪問過，那么 Linux 大概率就是從 Page cache 內存中的拷貝給你就完事，并不會有實際的磁盤 IO 發生。
不過有一種情況下，Pagecache 不會生效， 那就是你設置了 DIRECT_IO 標志。
1.5 文件系統
Linux 下支持的文件系統有很多，常用的有 ext2/3/4、XFS、ZFS 等。
要用哪種文件系統是在格式化的時候指定的。因為每一個分區都可以單獨進行格式化，所以一臺 Linux 機器下可以同時使用多個不同的文件系統。
文件系統里提供對 VFS 的具體實現。除了數據結構，每個文件系統還會定義自己的實際操作函數。例如在 ext4 中定義的 ext4_file_operations。在其中包含的VFS中定義的 read 函數的具體實現：do_sync_read 和 do_sync_write。
- const struct file_operations ext4_file_operations = {
- .llseek = ext4_llseek,
- .read = do_sync_read,
- .write = do_sync_write,
- .aio_read = generic_file_aio_read,
- .aio_write = ext4_file_write,
- ......
- }
和 VFS 不同的是，這里的函數就是實實在在的實現了。
1.6 通用塊層
文件系統還要依賴更下層的通用塊層。
對上層的文件系統，通用塊層提供一個統一的接口讓供文件系統實現者使用，而不用關心不同設備驅動程序的差異，這樣實現出來的文件系統就能用于任何的塊設備。通過對設備進行抽象后，不管是磁盤還是機械硬盤，對于文件系統都可以使用相同的接口對邏輯數據塊進行讀寫操作。
對下層。I/O 請求添加到設備的 I/O 請求隊列。它定義了一個叫 bio 的數據結構來表示一次 IO 操作請求(include/linux/bio.h)
1.7 IO 調度層
當通用塊層把 IO 請求實際發出以后，并不一定會立即被執行。因為調度層會從全局出發，盡量讓整體磁盤 IO 性能最大化。
對于機械硬盤來說，調度層會盡量讓磁頭類似電梯那樣工作，先往一個方向走，到頭再回來，這樣整體效率會比較高一些。具體的算法有 deadline 和 cfg ，算法細節就不展開了，感興趣同學可以自行搜索。
對于固態硬盤來說，隨機 IO 的問題已經被很大程度地解決了，所以可以直接使用最簡單的 noop 調度器。
在你的機器上，通過dmesg | grep -i scheduler來查看你的 Linux 支持的調度算法。
通用塊層和 IO 調度層一起為上層文件系統屏蔽了底層各種不同的硬盤、U盤的設備差異。
二、讀文件過程
我們已經把 Linux IO 棧里的各個內核組件都簡單介紹一遍了?，F在我們再從頭整體過一下讀取文件的過程(圖中源代碼基于 Linux 3.10)
這一張長圖把整個 Linux 讀取文件的過程都串了一遍。
三、回顧開篇問題
回到開篇的第一個問題：讀取文件 1 個字節是否會導致磁盤 IO ?
從上述流程中可以看到，如果 Page Cache 命中的話，根本就沒有磁盤 IO 產生。
所以，大家不要覺得代碼里出現幾個讀寫文件的邏輯就覺得性能會慢的不行。操作系統已經替你優化了很多很多，內存級別的訪問延遲大約是 ns 級別的，比機械磁盤 IO 快了好幾個數量級。如果你的內存足夠大，或者你的文件被訪問的足夠頻繁，其實這時候的 read 操作極少有真正的磁盤 IO 發生。
假如 Page Cache 沒有命中，那么一定會有傳動到機械軸上進行磁盤 IO 嗎?
其實也不一定，為什么，因為現在的磁盤本身就會帶一塊緩存。另外現在的服務器都會組建磁盤陣列，在磁盤陣列里的核心硬件Raid卡里也會集成RAM作為緩存。只有所有的緩存都不命中的時候，機械軸帶著磁頭才會真正工作。
再看開篇的第二個問題：如果發生了磁盤 IO，那發生的是多大的 IO 呢?
如果所有的 Cache 都沒有兜住 IO 讀請求，那么我們來看看實際 Linux 會讀取多大。真的按我們的需求來，只去讀一個字節嗎?
整個 IO 過程中涉及到了好幾個內核組件。而每個組件之間都是采用不同長度的塊來管理磁盤數據的。
- Page Cache 是以頁為單位的，Linux 頁大小一般是 4KB
- 文件系統是以塊(block)為單位來管理的。使用 dumpe2fs 可以查看，一般一個塊默認是 4KB
- 通用塊層是以段為單位來處理磁盤 IO 請求的，一個段為一個頁或者是頁的一部分
- IO 調度程序通過 DMA 方式傳輸 N 個扇區到內存，扇區一般為 512 字節
- 硬盤也是采用“扇區”的管理和傳輸數據的
可以看到，雖然我們從用戶角度確實是只讀了 1 個字節(開篇的代碼中我們只給這次磁盤IO留了一個字節的緩存區)。但是在整個內核工作流中，最小的工作單位是磁盤的扇區，為512字節，比1個字節要大的多。
另外 block、page cache 等高層組件工作單位更大。其中 Page Cache 的大小是一個內存頁 4KB。所以一般一次磁盤讀取是多個扇區(512字節)一起進行的。假設通用塊層 IO 的段就是一個內存頁的話，一次磁盤 IO 就是 4 KB(8 個 512 字節的扇區)一起進行讀取。
另外我們沒有講到的是還有一套復雜的預讀取的策略。所以，在實踐中，可能比 8 更多的扇區來一起被傳輸到內存中。
最后，啰嗦幾句
操作系統的本意是做到讓你簡單可依賴， 讓你盡量把它當成一個黑盒。你想要一個字節，它就給你一個字節，但是自己默默干了許許多多的活兒。
我們雖然國內絕大多數開發都不是搞底層的，但如果你十分關注你的應用程序的性能，你應該明白操作系統的什么時候悄悄提高了你的性能，是怎么來提高的。以便在將來某一個時候你的線上服務器扛不住快要掛掉的時候，你能迅速找出問題所在。
