轉載-什麼是inode？

什麼是inode？

來自： http://www.dbconf.net/inode-related-issues.html

inode是Linux/Unix系文件系統[如ext]中的一個概念，當一個文件系統格式化了之後，他必定會有 inode table 與 data area 兩個區塊。Block 是記錄文件內容數據的地區，而 inode 則是記錄該文件的屬性、及該文件放置在哪個 Block 以內的信息。並且每一個文件至少須要一個inode。

如何查詢一個文件系統的inode使用狀況：

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1            2366400  186064 2180336    8% /
none                   63327       1   63326    1% /dev/shm

使用df -i能夠看到文件系統的inode總數、使用數、剩餘量和使用百分比。

如何查看每一個文件系統的inode大小：定義inode大小：

 

 

[root@gc_server ~]# dumpe2fs -h /dev/sda1|grep node
dumpe2fs 1.35 (28-Feb-2004)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Inode count:              2366400
Free inodes:              2177496
Inodes per group:         16320
Inode blocks per group:   510
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       150509
Journal backup:           inode blocks

 

 

 

inode大小決定了一個文件系統中的inode總量，在建立文件系統的時候能夠指定inode的大小，建立以後不可修改：

mkfs.ext3 -I 128 /dev/sdb5   //自定inode的大小爲128byte

inode會引發什麼問題：

可能出現磁盤空閒空間充足的狀況下，新建文件時提示磁盤空間滿。

inode數量過多由什麼引發：

通常是小文件過多，若是一個文件大小比文件系統的塊大小還小，如文件系統的block size爲4k，而文件只有2k，則有2k的空間被浪費，也就是blocks per inode ratio太小，從而有可能會出現磁盤空間未滿，而inode數消耗殆盡的狀況。

如何規劃：

由於inode大小通常而言略大於block大小爲宜，因此：

一、 當 block 越小、inodes 越多，可利用空間越多，可是大文件寫入效率較差：適合文件數量多可是文件容量小的系統，例如 BBS 或者新聞羣組 news 這方面的服務之系統；

二、 當 block 越大 、 inodes 數越少，大文件寫入效率較佳，但浪費的空間較多：適合文件容量大的系統。

IO調度器

IO調度器的整體目標是但願讓磁頭可以老是往一個方向移動,移動到底了再往反方向走,這偏偏就是現實生活中的電梯模型,因此IO調度器也被叫作電梯.(elevator)而相應的算法也就被叫作電梯算法.而Linux中IO調度的電梯算法有好幾種,一個叫作as(Anticipatory),一個叫作cfq(Complete Fairness Queueing),一個叫作deadline,還有一個叫作noop(No Operation).具體使用哪一種算法咱們能夠在啓動的時候經過內核參數elevator來指定.

另外一方面咱們也能夠單獨的爲某個設備指定它所採用的IO調度算法,這就經過修改在/sys/block/sda/queue/目錄下面的scheduler文件.好比咱們能夠先看一下個人這塊硬盤:

[root@localhost ~]# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

能夠看到咱們這裏採用的是cfq.

Linux IO調度器相關算法介紹

IO調度器（IO Scheduler）是操做系統用來決定塊設備上IO操做提交順序的方法。存在的目的有兩個，一是提升IO吞吐量，二是下降IO響應時間。然而IO吞吐量和IO響應時間每每是矛盾的，爲了儘可能平衡這二者，IO調度器提供了多種調度算法來適應不一樣的IO請求場景。其中，對數據庫這種隨機讀寫的場景最有利的算法是DEANLINE。接着咱們按照從簡單到複雜的順序，迅速掃一下Linux 2.6內核提供的幾種IO調度算法。

一、NOOP

NOOP算法的全寫爲No Operation。該算法實現了最最簡單的FIFO隊列，全部IO請求大體按照先來後到的順序進行操做。之因此說「大體」，緣由是NOOP在FIFO的基礎上還作了相鄰IO請求的合併，並非完徹底全按照先進先出的規則知足IO請求。

假設有以下的io請求序列：

100，500，101，10，56，1000

NOOP將會按照以下順序知足：

100(101)，500，10，56，1000

二、CFQ

CFQ算法的全寫爲Completely Fair Queuing。該算法的特色是按照IO請求的地址進行排序，而不是按照先來後到的順序來進行響應。

假設有以下的io請求序列：

100，500，101，10，56，1000

CFQ將會按照以下順序知足：

100，101，500，1000，10，56

在傳統的SAS盤上，磁盤尋道花去了絕大多數的IO響應時間。CFQ的出發點是對IO地址進行排序，以儘可能少的磁盤旋轉次數來知足儘量多的IO請求。在CFQ算法下，SAS盤的吞吐量大大提升了。可是相比於NOOP的缺點是，先來的IO請求並不必定能被知足，可能會出現餓死的狀況。

三、DEADLINE

DEADLINE在CFQ的基礎上，解決了IO請求餓死的極端狀況。除了CFQ自己具備的IO排序隊列以外，DEADLINE額外分別爲讀IO和寫IO提供了FIFO隊列。讀FIFO隊列的最大等待時間爲500ms，寫FIFO隊列的最大等待時間爲5s。FIFO隊列內的IO請求優先級要比CFQ隊列中的高，，而讀FIFO隊列的優先級又比寫FIFO隊列的優先級高。優先級能夠表示以下：

FIFO(Read) > FIFO(Write) > CFQ

四、ANTICIPATORY

CFQ和DEADLINE考慮的焦點在於知足零散IO請求上。對於連續的IO請求，好比順序讀，並無作優化。爲了知足隨機IO和順序IO混合的場景，Linux還支持ANTICIPATORY調度算法。ANTICIPATORY的在DEADLINE的基礎上，爲每一個讀IO都設置了6ms的等待時間窗口。若是在這6ms內OS收到了相鄰位置的讀IO請求，就能夠當即知足。

IO調度器算法的選擇，既取決於硬件特徵，也取決於應用場景。

在傳統的SAS盤上，CFQ、DEADLINE、ANTICIPATORY都是不錯的選擇；對於專屬的數據庫服務器，DEADLINE的吞吐量和響應時間都表現良好。然而在新興的固態硬盤好比SSD、Fusion IO上，最簡單的NOOP反而多是最好的算法，由於其餘三個算法的優化是基於縮短尋道時間的，而固態硬盤沒有所謂的尋道時間且IO響應時間很是短。

查看和修改IO調度器的算法很是簡單。假設咱們要對sda進行操做，以下所示：

cat /sys/block/sda/queue/scheduler
echo 「cfq」 > /sys/block/sda/queue/scheduler

來自： http://www.sar4.com/2011/02/25/iostat%E5%92%8Ciowait.html