linux標准io

㈠ linux系統調用與標准io有什麼關聯

linux中，每個系統調用被賦予一個系統調用號，通過這個獨一無二的號就可以關聯系統調用了。 用戶空間的進程執行一個系統調用的時候，這個系統調用號就用來指明到底是要調用哪個系統調用，進程不會提及系統調用的名稱。 內核記錄了系統調用表中的...

㈡ linux查看磁碟io的幾種方法

linux查看磁碟io的幾種方法

怎樣才能快速的定位到並發高是由於磁碟io開銷大呢?可以通過三種方式：

第一種：用 top 命令 中的cpu 信息觀察

Top可以看到的cpu信息有：

Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si

具體的解釋如下：

Tasks: 29 total 進程總數

1 running 正在運行的進程數

28 sleeping 睡眠的進程數

0 stopped 停止的進程數

0 zombie 僵屍進程數

Cpu(s):

0.3% us 用戶空間佔用CPU百分比

1.0% sy 內核空間佔用CPU百分比

0.0% ni 用戶進程空間內改變過優先順序的進程佔用CPU百分比

98.7% id 空閑CPU百分比

0.0% wa 等待輸入輸出的CPU時間百分比

0.0% hi

0.0% si

0.0% wa 的百分比可以大致的體現出當前的磁碟io請求是否頻繁。如果 wa的數量比較大，說明等待輸入輸出的的io比較多。

第二種：用vmstat

vmstat 命令報告關於線程、虛擬內存、磁碟、陷阱和 CPU 活動的統計信息。由 vmstat 命令生成的報告可以用於平衡系統負載活動。系統范圍內的這些統計信息(所有的處理器中)都計算出以百分比表示的平均值，或者計算其總和。

輸入命令：

vmstat 2 5

如果發現等待的進程和處在非中斷睡眠狀態的進程數非常多，並且發送到塊設備的塊數和從塊設備接收到的塊數非常大，那就說明磁碟io比較多。

vmstat參數解釋：

Procs

r: 等待運行的進程數 b: 處在非中斷睡眠狀態的進程數 w: 被交換出去的可運行的進程數。此數由 linux 計算得出，但 linux 並不耗盡交換空間

Memory

swpd: 虛擬內存使用情況，單位：KB

free: 空閑的內存，單位KB

buff: 被用來做為緩存的內存數，單位：KB

Swap

si: 從磁碟交換到內存的交換頁數量，單位：KB/秒

so: 從內存交換到磁碟的交換頁數量，單位：KB/秒

IO

bi: 發送到塊設備的塊數，單位：塊/秒

bo: 從塊設備接收到的塊數，單位：塊/秒

System

in: 每秒的中斷數，包括時鍾中斷

cs: 每秒的環境(上下文)切換次數

CPU

按 CPU 的總使用百分比來顯示

us: CPU 使用時間

sy: CPU 系統使用時間

id: 閑置時間

准測

更多vmstat使用信息

第二種：用iostat

安裝:

Iostat 是 sysstat 工具集的一個工具，需要安裝。

Centos的安裝方式是：

yum install sysstat

Ubuntu的安裝方式是：

aptitude install sysstat

使用：

iostat -dx 顯示磁碟擴展信息

root@fileapp:~# iostat -dx

r/s 和 w/s 分別是每秒的讀操作和寫操作，而rKB/s 和wKB/s 列以每秒千位元組為單位顯示了讀和寫的數據量

如果這兩對數據值都很高的話說明磁碟io操作是很頻繁。

+++++++++++++++++++++++++++++++++++++

linux wa%過高，iostat查看io狀況

1, 安裝  iostat  

yum install sysstat

之後就可以使用 iostat 命令了，

2，入門使用

iostat -d -k 2

參數 -d 表示，顯示設備（磁碟）使用狀態；-k某些使用block為單位的列強制使用Kilobytes為單位；2表示，數據顯示每隔2秒刷新一次。

tps：該設備每秒的傳輸次數（Indicate the number of transfers per second that were issued to the device.）。"一次傳輸"意思是"一次I/O請求"。多個邏輯請求可能會被合並為"一次I/O請求"。"一次傳輸"請求的大小是未知的。kB_read/s：每秒從設備（drive expressed）讀取的數據量；

kB_wrtn/s：每秒向設備（drive expressed）寫入的數據量；

kB_read：讀取的總數據量；kB_wrtn：寫入的總數量數據量；這些單位都為Kilobytes。

指定監控的設備名稱為sda，該命令的輸出結果和上面命令完全相同。

iostat -d sda 2

默認監控所有的硬碟設備，現在指定只監控sda。 

3, -x 參數

iostat還有一個比較常用的選項 -x ，該選項將用於顯示和io相關的擴展數據。

iostat -d -x -k 1 10

輸出信息的含義

。

4, 常見用法

iostat -d -k 1 10        #查看TPS和吞吐量信息(磁碟讀寫速度單位為KB)

iostat -d -m 2            #查看TPS和吞吐量信息(磁碟讀寫速度單位為MB)

iostat -d -x -k 1 10      #查看設備使用率（%util）、響應時間（await） iostat -c 1 10 #查看cpu狀態

5, 實例分析

iostat -d -k 1 | grep vda

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

sda10            60.72        18.95        71.53  395637647 1493241908

sda10          299.02      4266.67      129.41      4352        132

sda10          483.84      4589.90      4117.17      4544      4076

sda10          218.00      3360.00      100.00      3360        100

sda10          546.00      8784.00      124.00      8784        124

sda10          827.00    13232.00      136.00      13232        136

上面看到，磁碟每秒傳輸次數平均約400；每秒磁碟讀取約5MB，寫入約1MB。

iostat -d -x -k 1

Device:    rrqm/s wrqm/s  r/s  w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz  await  svctm  %util

sda          1.56  28.31  7.84 31.50  43.65    3.16    21.82    1.58    1.19    0.03    0.80  2.61  10.29

sda          1.98  24.75 419.80  6.93 13465.35  253.47  6732.67  126.73    32.15    2.00    4.70  2.00  85.25

sda          3.06  41.84 444.90 54.08 14204.08 2048.98  7102.04  1024.49    32.57    2.10    4.21  1.85  92.24

可以看到磁碟的平均響應時間<5ms，磁碟使用率>80。磁碟響應正常，但是已經很繁忙了。

可以看到磁碟的平均響應時間<5ms，磁碟使用率>90。磁碟響應正常，但是已經很繁忙了。

await：  每一個IO請求的處理的平均時間（單位是微秒毫秒）。這里可以理解為IO的響應時間，一般地系統IO響應時間應該低於5ms，如果大於10ms就比較大了

svctm    表示平均每次設備I/O操作的服務時間（以毫秒為單位）。如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁碟性能很好，

如果await的值遠高於svctm的值，則表示I/O隊列等待太長，  系統上運行的應用程序將變慢。

%util： 在統計時間內所有處理IO時間，除以總共統計時間

所以該參數暗示了設備的繁忙程度

。一般地，如果該參數是100%表示設備已經接近滿負荷運行了（當然如果是多磁碟，即使%util是100%，因為磁碟的並發能力，所以磁碟使用未必就到了瓶頸）。

也可以使用下面的命令，同時顯示cpu和磁碟的使用情況

等待時間超過5ms, 磁碟io有問題

㈢ Linux系統I/O模型及select、poll、epoll原理和應用

理解Linux的IO模型之前，首先要了解一些基本概念，才能理解這些IO模型設計的依據

操作系統使用虛擬內存來映射物理內存，對於32位的操作系統來說，虛擬地址空間為4G（2^32）。操作系統的核心是內核，為了保護用戶進程不能直接操作內核，保證內核安全，操作系統將虛擬地址空間劃分為內核空間和用戶空間。內核可以訪問全部的地址空間，擁有訪問底層硬體設備的許可權，普通的應用程序需要訪問硬體設備必須通過 系統調用 來實現。

對於Linux系統來說，將虛擬內存的最高1G位元組的空間作為內核空間僅供內核使用，低3G位元組的空間供用戶進程使用，稱為用戶空間。

又被稱為標准I/O，大多數文件系統的默認I/O都是緩存I/O。在Linux系統的緩存I/O機制中，操作系統會將I/O的數據緩存在頁緩存（內存）中，也就是數據先被拷貝到內核的緩沖區（內核地址空間），然後才會從內核緩沖區拷貝到應用程序的緩沖區（用戶地址空間）。

這種方式很明顯的缺點就是數據傳輸過程中需要再應用程序地址空間和內核空間進行多次數據拷貝操作，這些操作帶來的CPU以及內存的開銷是非常大的。

由於Linux系統採用的緩存I/O模式，對於一次I/O訪問，以讀操作舉例，數據先會被拷貝到內核緩沖區，然後才會從內核緩沖區拷貝到應用程序的緩存區，當一個read系統調用發生的時候，會經歷兩個階段：

正是因為這兩個狀態，Linux系統才產生了多種不同的網路I/O模式的方案

Linux系統默認情況下所有socke都是blocking的，一個讀操作流程如下：

以UDP socket為例，當用戶進程調用了recvfrom系統調用，如果數據還沒准備好，應用進程被阻塞，內核直到數據到來且將數據從內核緩沖區拷貝到了應用進程緩沖區，然後向用戶進程返回結果，用戶進程才解除block狀態，重新運行起來。

阻塞模行下只是阻塞了當前的應用進程，其他進程還可以執行，不消耗CPU時間，CPU的利用率較高。

Linux可以設置socket為非阻塞的，非阻塞模式下執行一個讀操作流程如下：

當用戶進程發出recvfrom系統調用時，如果kernel中的數據還沒准備好，recvfrom會立即返回一個error結果，不會阻塞用戶進程，用戶進程收到error時知道數據還沒准備好，過一會再調用recvfrom，直到kernel中的數據准備好了，內核就立即將數據拷貝到用戶內存然後返回ok，這個過程需要用戶進程去輪詢內核數據是否准備好。

非阻塞模型下由於要處理更多的系統調用，因此CPU利用率比較低。

應用進程使用sigaction系統調用，內核立即返回，等到kernel數據准備好時會給用戶進程發送一個信號，告訴用戶進程可以進行IO操作了，然後用戶進程再調用IO系統調用如recvfrom，將數據從內核緩沖區拷貝到應用進程。流程如下：

相比於輪詢的方式，不需要多次系統調用輪詢，信號驅動IO的CPU利用率更高。

非同步IO模型與其他模型最大的區別是，非同步IO在系統調用返回的時候所有操作都已經完成，應用進程既不需要等待數據准備，也不需要在數據到來後等待數據從內核緩沖區拷貝到用戶緩沖區，流程如下：

在數據拷貝完成後，kernel會給用戶進程發送一個信號告訴其read操作完成了。

是用select、poll等待數據，可以等待多個socket中的任一個變為可讀，這一過程會被阻塞，當某個套接字數據到來時返回，之後再用recvfrom系統調用把數據從內核緩存區復制到用戶進程，流程如下：

流程類似阻塞IO，甚至比阻塞IO更差，多使用了一個系統調用，但是IO多路復用最大的特點是讓單個進程能同時處理多個IO事件的能力，又被稱為事件驅動IO，相比於多線程模型，IO復用模型不需要線程的創建、切換、銷毀，系統開銷更小，適合高並發的場景。

select是IO多路復用模型的一種實現，當select函數返回後可以通過輪詢fdset來找到就緒的socket。

優點是幾乎所有平台都支持，缺點在於能夠監聽的fd數量有限，Linux系統上一般為1024，是寫死在宏定義中的，要修改需要重新編譯內核。而且每次都要把所有的fd在用戶空間和內核空間拷貝，這個操作是比較耗時的。

poll和select基本相同，不同的是poll沒有最大fd數量限制（實際也會受到物理資源的限制，因為系統的fd數量是有限的），而且提供了更多的時間類型。

總結：select和poll都需要在返回後通過輪詢的方式檢查就緒的socket，事實上同時連的大量socket在一個時刻只有很少的處於就緒狀態，因此隨著監視的描述符數量的變多，其性能也會逐漸下降。

epoll是select和poll的改進版本，更加靈活，沒有描述符限制。epoll使用一個文件描述符管理多個描述符，將用戶關系的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的只需一次。

epoll_create()用來創建一個epoll句柄。
epoll_ctl() 用於向內核注冊新的描述符或者是改變某個文件描述符的狀態。已注冊的描述符在內核中會被維護在一棵紅黑樹上，通過回調函數內核會將 I/O 准備好的描述符加入到一個就緒鏈表中管理。
epoll_wait() 可以從就緒鏈表中得到事件完成的描述符，因此進程不需要通過輪詢來獲得事件完成的描述符。

當epoll_wait檢測到描述符IO事件發生並且通知給應用程序時，應用程序可以不立即處理該事件，下次調用epoll_wait還會再次通知該事件，支持block和nonblocking socket。

當epoll_wait檢測到描述符IO事件發生並且通知給應用程序時，應用程序需要立即處理該事件，如果不立即處理，下次調用epoll_wait不會再次通知該事件。

ET模式在很大程度上減少了epoll事件被重復觸發的次數，因此效率要比LT模式高。epoll工作在ET模式的時候，必須使用nonblocking socket，以避免由於一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。

【segmentfault】 Linux IO模式及 select、poll、epoll詳解
【GitHub】 CyC2018/CS-Notes

㈣ Linux的五種IO模型

在linux中，對於一次讀取IO請求（不僅僅是磁碟，還有網路）的操作，數據並不會直接拷貝到用戶程序的用戶空間緩沖區。它首先會被拷貝到操作系統的內核空間，然後才會從操作系統內核的緩沖區拷貝到用戶空間的緩沖區。
大概是這個樣子。

從圖中可以看見，這是分四步進行的，而這四步裡面有些細節，就有了這5種IO模型

前四種為同步IO，後一種為非同步IO，什麼是同步非同步可以看看我之前寫的 同步與非同步，阻塞與非阻塞 。

應用進程發起系統調用後就阻塞了，直到內核buffer拷貝到用戶buffer，發出成功提示後才繼續執行。

適用場景：並發量小的要及時響應的網路應用開發，JavaBIO。
優點：易於開發，不消耗CPU資源（線程阻塞），及時響應。
缺點：不適用與並發量大的網路應用開發，一個請求一個線程，系統開銷大。

應用進程發起系統調用，內核立馬返回一個自己當前的緩沖區的狀態（錯誤或者說成功），假如
為錯誤則隔段時間再系統調用（輪詢），直到返回成功為止。另外再說一點，有人說輪詢之間可以設置一個時間，例如每幾秒執行一次，然後在這段期間程序可以干自己的事情。（這個我不清楚是不是，雖然理論上可以實現，但是我覺得第一種與第二種的區別應該強調的是是否放棄CPU，第二種有點CAS+輪詢這種輕量級鎖的感覺，第一種就是那種重量級鎖的感覺）。

適用場景：並發量小且不用技術響應的網路應用開發
優點：易於開發，可以在輪詢的間斷期間繼續執行程序。
缺點：不適用與並發量大的網路應用開發，一個請求一個線程，系統開銷大。消耗CPU資源（輪詢），不及時響應。

將多個IO注冊到一個復用器上（select，poll，epoll），然後一個進程監視所有注冊進來的IO。
進程阻塞在select上，而不是真正阻塞在IO系統調用上。當其中任意一個注冊的IO的內核緩沖區有了數據，select就會返回（告訴程序內核態緩存有數據了），然後用戶進程再發起調用，數據就從內核態buffer轉到用態buffer（這段期間也是要阻塞的）。

適用場景：並發量大且對響應要求較為高的網路應用開發，JavaNIO
優點：將阻塞從多個進程轉移到了一個select調用身上，假如並發量大的話select調用是不易被阻塞的，或者說阻塞時間短的。
缺點：不易開發，實現難度大，當並發量小的時候還不如同步阻塞模型。

應用程序向內核注冊一個信號處理程序，然後立即返回，當數據准備好了以後（數據到了內核buffer），內核個應用進程一個信號，然後應用進程通過信號處理程序發起系統調用，然後阻塞直達數據從內核buffer復制到用戶buffer。

優點：將阻塞從多個進程轉移到了一個select調用身上，假如並發量大的話select調用是不易被阻塞的，或者說阻塞時間短的。
缺點：不易開發，實現難度大。

以上四個IO模型都可以看出來，到最後用戶進程都要在數據從內核buffer復制到用戶buffer時阻塞，直到內核告訴進程准備成功。這就是同步進程，就是發出一個功能調用時，在沒有得到結果之前，該調用就不返回或繼續執行後續操作。

就是發出一個功能調用時，在沒有得到結果之前，該調用就不返回或繼續執行後續操作

這個就是直到數據完成到用戶buffer才通知。

應用場景：Java AIO，適合高性能高並發應用。
優點：不阻塞，減少了線程切換，
缺點：難以實現，要操作系統支持。

㈤ linux中的io操作指的是什麼

計算機中的I/O匯流排（輸入輸出匯流排），主要用於聯系硬碟、USB、網卡等介面設備，和這些設備的數據「交流」（讀與寫），就可以叫做I/O操作。

㈥ Linux 磁碟IO

磁碟結構與數據存儲方式, 數據是如何存儲的，又通過怎樣的方式被訪問？

機械硬碟主要由磁碟碟片、磁頭、主軸與傳動軸等組成；數據就存放在磁碟碟片中

現代硬碟尋道都是採用CHS( Cylinder Head Sector )的方式，硬碟讀取數據時，讀寫磁頭沿徑向移動，移到要讀取的扇區所在磁軌的上方，這段時間稱為 尋道時間(seek time) 。 因讀寫磁頭的起始位置與目標位置之間的距離不同，尋道時間也不同 。磁頭到達指定磁軌後，然後通過碟片的旋轉，使得要讀取的扇區轉到讀寫磁頭的下方，這段時間稱為 旋轉延遲時間(rotational latencytime) 。然後再讀寫數據，讀寫數據也需要時間，這段時間稱為 傳輸時間(transfer time) 。

固態硬碟主要由主控晶元、快閃記憶體顆粒與緩存組成；數據就存放在快閃記憶體晶元中
通過主控晶元進行定址， 因為是電信號方式， 沒有任何物理結構， 所以定址速度非常快且與數據存儲位置無關

如何查看系統IO狀態

查看磁碟空間

調用 open , fwrite 時到底發生了什麼?

在一個IO過程中，以下5個API/系統調用是必不可少的
Create 函數用來打開一個文件，如果該文件不存在，那麼需要在磁碟上創建該文件
Open 函數用於打開一個指定的文件。如果在 Open 函數中指定 O_CREATE 標記，那麼 Open 函數同樣可以實現 Create 函數的功能
Clos e函數用於釋放文件句柄
Write 和 Read 函數用於實現文件的讀寫過程

O_SYNC (先寫緩存, 但是需要實際落盤之後才返回, 如果接下來有讀請求, 可以從內存讀 ), write-through
O_DSYNC (D=data, 類似O_SYNC, 但是只同步數據, 不同步元數據)
O_DIRECT (直接寫盤, 不經過緩存)
O_ASYNC (非同步IO, 使用信號機制實現, 不推薦, 直接用aio_xxx)
O_NOATIME (讀取的時候不更新文件 atime(access time))

sync() 全局緩存寫回磁碟
fsync() 特定fd的sync()
fdatasync() 只刷數據, 不同步元數據

mount noatime(全局不記錄atime), re方式(只讀), sync(同步方式)

一個IO的傳奇一生 這里有一篇非常好的資料，講述了整個IO過程；
下面簡單記錄下自己的理解的一次常見的Linux IO過程， 想了解更詳細及相關源碼，非常推薦閱讀上面的原文

Linux IO體系結構

[站外圖片上傳中...(image-38a7b-1644137945193)]

Superblock 超級描述了整個文件系統的信息。為了保證可靠性，可以在每個塊組中對superblock進行備份。為了避免superblock冗餘過多，可以採用稀疏存儲的方式，即在若干個塊組中對superblock進行保存，而不需要在所有的塊組中都進行備份
GDT 組描述符表 組描述符表對整個組內的數據布局進行了描述。例如，數據塊點陣圖的起始地址是多少？inode點陣圖的起始地址是多少？inode表的起始地址是多少？塊組中還有多少空閑塊資源等。組描述符表在superblock的後面
數據塊點陣圖 數據塊點陣圖描述了塊組內數據塊的使用情況。如果該數據塊已經被某個文件使用，那麼點陣圖中的對應位會被置1，否則該位為0
Inode點陣圖 Inode點陣圖描述了塊組內inode資源使用情況。如果一個inode資源已經使用，那麼對應位會被置1
Inode表 （即inode資源）和數據塊。這兩塊占據了塊組內的絕大部分空間，特別是數據塊資源

一個文件是由inode進行描述的。一個文件佔用的數據塊block是通過inode管理起來的 。在inode結構中保存了直接塊指針、一級間接塊指針、二級間接塊指針和三級間接塊指針。對於一個小文件，直接可以採用直接塊指針實現對文件塊的訪問；對於一個大文件，需要採用間接塊指針實現對文件塊的訪問

最簡單的調度器。它本質上就是一個鏈表實現的 fifo 隊列，並對請求進行簡單的 合並 處理。
調度器本身並沒有提供任何可以配置的參數

讀寫請求被分成了兩個隊列， 一個用訪問地址作為索引，一個用進入時間作為索引，並且採用兩種方式將這些request管理起來；
在請求處理的過程中，deadline演算法會優先處理那些訪問地址臨近的請求，這樣可以最大程度的減少磁碟抖動的可能性。
只有在有些request即將被餓死的時候，或者沒有辦法進行磁碟順序化操作的時候，deadline才會放棄地址優先策略，轉而處理那些即將被餓死的request

deadline演算法可調整參數
read_expire : 讀請求的超時時間設置(ms)。當一個讀請求入隊deadline的時候，其過期時間將被設置為當前時間＋read_expire，並放倒fifo_list中進行排序
write_expire :寫請求的超時時間設置(ms)
fifo_batch :在順序（sort_list）請求進行處理的時候，deadline將以batch為單位進行處理。每一個batch處理的請求個數為這個參數所限制的個數。在一個batch處理的過程中，不會產生是否超時的檢查，也就不會產生額外的磁碟尋道時間。這個參數可以用來平衡順序處理和飢餓時間的矛盾，當飢餓時間需要盡可能的符合預期的時候，我們可以調小這個值，以便盡可能多的檢查是否有飢餓產生並及時處理。增大這個值當然也會增大吞吐量，但是會導致處理飢餓請求的延時變長
writes_starved :這個值是在上述deadline出隊處理第一步時做檢查用的。用來判斷當讀隊列不為空時，寫隊列的飢餓程度是否足夠高，以時deadline放棄讀請求的處理而處理寫請求。當檢查存在有寫請求的時候，deadline並不會立即對寫請求進行處理，而是給相關數據結構中的starved進行累計，如果這是第一次檢查到有寫請求進行處理，那麼這個計數就為1。如果此時writes_starved值為2，則我們認為此時飢餓程度還不足夠高，所以繼續處理讀請求。只有當starved >= writes_starved的時候，deadline才回去處理寫請求。可以認為這個值是用來平衡deadline對讀寫請求處理優先順序狀態的，這個值越大，則寫請求越被滯後處理，越小，寫請求就越可以獲得趨近於讀請求的優先順序
front_merges :當一個新請求進入隊列的時候，如果其請求的扇區距離當前扇區很近，那麼它就是可以被合並處理的。而這個合並可能有兩種情況，一個是向當前位置後合並，另一種是向前合並。在某些場景下，向前合並是不必要的，那麼我們就可以通過這個參數關閉向前合並。默認deadline支持向前合並，設置為0關閉

在調度一個request時，首先需要選擇一個一個合適的cfq_group。Cfq調度器會為每個cfq_group分配一個時間片，當這個時間片耗盡之後，會選擇下一個cfq_group。每個cfq_group都會分配一個vdisktime，並且通過該值採用紅黑樹對cfq_group進行排序。在調度的過程中，每次都會選擇一個vdisktime最小的cfq_group進行處理。
一個cfq_group管理了7棵service tree，每棵service tree管理了需要調度處理的對象cfq_queue。因此，一旦cfq_group被選定之後，需要選擇一棵service tree進行處理。這7棵service tree被分成了三大類，分別為RT、BE和IDLE。這三大類service tree的調度是按照優先順序展開的

通過優先順序可以很容易的選定一類Service tree。當一類service tree被選定之後，採用service time的方式選定一個合適的cfq_queue。每個Service tree是一棵紅黑樹，這些紅黑樹是按照service time進行檢索的，每個cfq_queue都會維護自己的service time。分析到這里，我們知道，cfq演算法通過每個cfq_group的vdisktime值來選定一個cfq_group進行服務，在處理cfq_group的過程通過優先順序選擇一個最需要服務的service tree。通過該Service tree得到最需要服務的cfq_queue。該過程在 cfq_select_queue 函數中實現

一個cfq_queue被選定之後，後面的過程和deadline演算法有點類似。在選擇request的時候需要考慮每個request的延遲等待時間，選擇那種等待時間最長的request進行處理。但是，考慮到磁碟抖動的問題，cfq在處理的時候也會進行順序批量處理，即將那些在磁碟上連續的request批量處理掉

cfq調度演算法的參數
back_seek_max :磁頭可以向後定址的最大范圍，默認值為16M
back_seek_penalty :向後定址的懲罰系數。這個值是跟向前定址進行比較的

fifo_expire_async :設置非同步請求的超時時間。同步請求和非同步請求是區分不同隊列處理的，cfq在調度的時候一般情況都會優先處理同步請求，之後再處理非同步請求，除非非同步請求符合上述合並處理的條件限制范圍內。當本進程的隊列被調度時，cfq會優先檢查是否有非同步請求超時，就是超過fifo_expire_async參數的限制。如果有，則優先發送一個超時的請求，其餘請求仍然按照優先順序以及扇區編號大小來處理
fifo_expire_sync :這個參數跟上面的類似，區別是用來設置同步請求的超時時間
slice_idle :參數設置了一個等待時間。這讓cfq在切換cfq_queue或service tree的時候等待一段時間，目的是提高機械硬碟的吞吐量。一般情況下，來自同一個cfq_queue或者service tree的IO請求的定址局部性更好，所以這樣可以減少磁碟的定址次數。這個值在機械硬碟上默認為非零。當然在固態硬碟或者硬RAID設備上設置這個值為非零會降低存儲的效率，因為固態硬碟沒有磁頭定址這個概念，所以在這樣的設備上應該設置為0，關閉此功能
group_idle :這個參數也跟上一個參數類似，區別是當cfq要切換cfq_group的時候會等待一段時間。在cgroup的場景下，如果我們沿用slice_idle的方式，那麼空轉等待可能會在cgroup組內每個進程的cfq_queue切換時發生。這樣會如果這個進程一直有請求要處理的話，那麼直到這個cgroup的配額被耗盡，同組中的其它進程也可能無法被調度到。這樣會導致同組中的其它進程餓死而產生IO性能瓶頸。在這種情況下，我們可以將slice_idle ＝ 0而group_idle ＝ 8。這樣空轉等待就是以cgroup為單位進行的，而不是以cfq_queue的進程為單位進行，以防止上述問題產生
low_latency :這個是用來開啟或關閉cfq的低延時（low latency）模式的開關。當這個開關打開時，cfq將會根據target_latency的參數設置來對每一個進程的分片時間（slice time）進行重新計算。這將有利於對吞吐量的公平（默認是對時間片分配的公平）。關閉這個參數（設置為0）將忽略target_latency的值。這將使系統中的進程完全按照時間片方式進行IO資源分配。這個開關默認是打開的

target_latency :當low_latency的值為開啟狀態時，cfq將根據這個值重新計算每個進程分配的IO時間片長度
quantum :這個參數用來設置每次從cfq_queue中處理多少個IO請求。在一個隊列處理事件周期中，超過這個數字的IO請求將不會被處理。這個參數只對同步的請求有效
slice_sync :當一個cfq_queue隊列被調度處理時，它可以被分配的處理總時間是通過這個值來作為一個計算參數指定的。公式為： time_slice = slice_sync + (slice_sync/5 * (4 - prio)) 這個參數對同步請求有效
slice_async :這個值跟上一個類似，區別是對非同步請求有效
slice_async_rq :這個參數用來限制在一個slice的時間范圍內，一個隊列最多可以處理的非同步請求個數。請求被處理的最大個數還跟相關進程被設置的io優先順序有關

通常在Linux上使用的IO介面是同步方式的，進程調用 write / read 之後會阻塞陷入到內核態，直到本次IO過程完成之後，才能繼續執行，下面介紹的非同步IO則沒有這種限制，但是當前Linux非同步IO尚未成熟

目前Linux aio還處於較不成熟的階段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是無法使用默認的Page Cache機制

正常情況下，使用aio族介面的簡要方式如下：

io_uring 是 2019 年 5 月發布的 Linux 5.1 加入的一個重大特性 —— Linux 下的全新的非同步 I/O 支持，希望能徹底解決長期以來 Linux AIO 的各種不足
io_uring 實現非同步 I/O 的方式其實是一個生產者-消費者模型:

邏輯卷管理
RAID0
RAID1
RAID5（糾錯）
條帶化

Linux系統性能調整：IO過程
Linux的IO調度
一個IO的傳奇一生
理解inode
Linux 文件系統是怎麼工作的？
Linux中Buffer cache性能問題一探究竟
Asynchronous I/O and event notification on linux
AIO 的新歸宿：io_uring
Linux 文件 I/O 進化史（四）：io_uring —— 全新的非同步 I/O

㈦ LINUX，有名管道和無名管道問題。 為什麼這2者都要通過文件描述符（文件IO）來操作呢，可以用標准IO

管道通過read和write來進行操作，這才是標准IO。
fread和fwrite是操作文件描述符的，即FILE *。
系統中所有的描述符（文件，管道，通信，各種設備等等）都可以用int表示，都可以read/write。但是這些描述符卻無法都用FILE*來表示。FILE*只適合用於文件。 fileno()函數可以把FILE*轉化為int。會正確使用read和write才是王道。

㈧ Linux使用標准I/O編寫程序，獲取用戶指定目錄的目錄列表

在沒有圖形界面的Linux中需要查看一個文件的內容，這里分享下查找方法。

1、首先在電腦中打開Putty軟體，連接上Linux，如下圖所示。