linux塊設備加速緩存之bcache

什麼是bcache 轉載請注明出處：http://blog.csdn.net/liumangxiong bcache是linux內核塊層cache。它使用類似SSD來作為HDD硬盤的cache，從而起到加速作用。 HDD硬盤便宜並且空間更大，SSD速度快但更貴。如果能兩者兼得，豈不快哉？bcache能做到。 bcache使用SSD作為其他塊設備cache。類似ZFS的L2Arc，但bcache還增加了寫回策略，並且是與文件系統無關的。bcache被設計成只需要最小的代價，無需配置就能在所有環境中工作。默認狀態下bcache不緩存順序IO，只緩存隨機讀寫。bcache適用於桌面、服務器，高級存儲陣列，甚至是嵌入式環境。 設計bcache目標是讓被緩存設備與SSD一樣快（包括緩存命中、緩存不命中、透寫和回寫）。現在還未達到初衷，特別是順序寫。同時測試結果表明離目標很接近，甚至有些情況下表現更好，例如隨機寫。 bcache是數據安全的。對於寫回策略緩存來說，可靠性是非常重要的，出錯就意味著丟失數據。bcache是用電池備份陣列控制器的替代選擇，同時也要求bcache在異常掉電時也是數據安全的。對於寫而言，必須在所有數據寫到可靠介質之後才能向上層返回寫成功，在異常掉電情況下，寫不能是部分完成的。大量工作已經投入到這部分數據安全的工作中。 bcache性能設計目標是等同於SSD。最大程度上去最小化寫放大，並避免隨機寫。bcache將隨機寫轉換為順序寫，首先寫到SSD，然後回寫緩存使用SSD緩存大量的寫，最後將寫有序寫到磁盤或者陣列上。對於RAID6陣列，隨機寫性能很差，還要花費不菲的價格購買帶有電池保護的陣列控制器。現在有了bcache，你就可以直接使用linux自帶的優秀軟RAID，甚至可以在更廉價的硬件上獲取更高的隨機寫性能。
特性 1、一個緩存設備可以作為多個設備的緩存，並且可以在設備運行時動態添加和刪除緩存。 2、異常關機恢復，只有當寫到磁盤後緩存才會確認寫完成。 3、正確處理寫阻塞和刷緩存 4、支持writethrough, writeback和writearound 5、檢測並避開順序IO（可配置關閉該選項） 6、當檢測到SSD延遲超過配置邊界值，減少到SSD流量（當一個SSD作為多個磁盤緩存時使用） 7、緩存不命中時預讀（默認關閉） 8、高性能的writeback實現：髒數據都是排序後再回寫。如果設置了writeback水位線，PD控制器會根據髒數據比例來平滑處理到後台writeback流量。 9、使用高效率了B+樹，bcache隨機讀可以達到1M IOPS 10、穩定，已經有產品應用

性能
7/25/12 隨機測試 在我的測試機上，我將SSD盤劃分為兩個相同大小的分區，一個分區用於測試SSD裸盤，另一個作為硬盤緩存。 bcache配置修改：cache_mode設置為writeback，writeback_percent設置為40。（如果writeback_percent不為0，bcache使用PD控制器根據緩存的髒數據塊來平滑處理下發到磁盤的流量）。同時還關閉了擁塞閥值，因為當SSD延遲達到極限時，如果bcache切換到writethrough將會影響結果。 SSD盤為Intel 160G MLC SSD，也就是Intel SSDSA2M160。 FIO作為性能測試，測試腳本如下： [global] randrepeat=1 ioengine=libaio bs=4k ba=4k size=8G direct=1 gtod_reduce=1 norandommap iodepth=64 FIO運行在SSD裸設備上，但對於這類性能測試軟件來說應該沒有影響。 裸SSD設備上隨機寫測試結果如下：

root@utumno:~# fio ~/rw4k

randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio 1.59
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/49885K /s] [0 /12.2K iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=1): err= 0: pid=1770
  write: io=8192.3MB, bw=47666KB/s, iops=11916 , runt=175991msec
  cpu          : usr=4.33%, sys=14.28%, ctx=2071968, majf=0, minf=19
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued r/w/d: total=0/2097215/0, short=0/0/0

Run status group 0 (all jobs):
  WRITE: io=8192.3MB, aggrb=47666KB/s, minb=48810KB/s, maxb=48810KB/s, mint=175991msec, maxt=175991msec

Disk stats (read/write):
  sdb: ios=69/2097888, merge=0/3569, ticks=0/11243992, in_queue=11245600, util=99.99%

添加了bcache：

root@utumno:~# fio ~/rw4k

randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio 1.59
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/75776K /s] [0 /18.5K iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=1): err= 0: pid=1914
  write: io=8192.3MB, bw=83069KB/s, iops=20767 , runt=100987msec
  cpu          : usr=3.17%, sys=13.27%, ctx=456026, majf=0, minf=19
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued r/w/d: total=0/2097215/0, short=0/0/0

Run status group 0 (all jobs):
  WRITE: io=8192.3MB, aggrb=83068KB/s, minb=85062KB/s, maxb=85062KB/s, mint=100987msec, maxt=100987msec

Disk stats (read/write):
  bcache0: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

添加了bcache之後IOPS為18.5K，裸SSD設備為12.2K。bcache表現更佳是因為bcache按順序將寫請求發送到SSD，但額外加入了更新索引的開銷。bcache對隨機寫做了優化，bcache還從高IO深度（64）獲益，因為在高IO深度的情況下就可以將多次下標更新合並為一次寫請求。 高IO深度就代表著高系統負載，當IO深度下調時IOPS也出現變化：

IO depth of 32: bcache 20.3k iops, raw ssd 19.8k iops

IO depth of 16: bcache 16.7k iops, raw ssd 23.5k iops

IO depth of 8: bcache 8.7k iops, raw ssd 14.9k iops

IO depth of 4: bcache 8.9k iops, raw ssd 19.7k iops

SSD性能在不同IO深度時出現了波動。對於不同的寫模型會有不同的結果，我們只關注兩者的相對數值。
當測試隨機4K寫，IO深度為1時，bcache寫次數是裸SSD設備的兩倍：每一次寫都需要再更新一次索引。

隨機讀

IO depth of 64: bcache 29.5k iops, raw ssd 25.4k iops

IO depth of 16: bcache 28.2k iops, raw ssd 27.6k iops

bcache略勝一籌，可能跟要讀的數據相關。這裡的結論是隨機讀時bcache與裸SSD讀性能是相同的。 這裡要注意的是，讀4K隨機寫下去的數據，這樣的測試模型對於bcache是不好的。這意味btree都是4K大小，btree將比通常時候大得多。在實際應用中，平均大小是100K。btree變大就意味著索引占用更大的內存空間，並且有一部分是在二級索引。根據個人經驗這些開銷在大型機器IOPS超過500K時才會有實際影響。 如果大家有其他的測試方法或者我的測試方法中有什麼問題請通知郵件告訴我。
常見問題 關機、設備移除 系統關機時cache仍然是髒的，就是說後端磁盤的數據並不可靠。如果要保證後端磁盤數據是安全的，就需要手動移動cache或者將cache設置為writethrough模式。 自動掛載 bcache會自動匹配cache和後端設備。匹配過程與設備對系統可用的次序沒有關系。 帶bcache的根目錄分區 為了讓根分區能夠使用bcache，需要添加rootdelay=3到啟動參數，這樣才能讓udev規則在系統mount根文件系統之前運行。 已格式化過的磁盤或分區 如果一個分區或者磁盤設備啟動時沒有創建bcache，可能是因為超級塊發生錯誤。為了讓bcache能夠正確檢測到之前的設備，udev規則會首先檢查是否符合bcache規則和blkid檢查。udev規則檢查設備超級塊從而識別文件系統類型，如果該超級塊不符合bcache文件系統類型那麼就不會添加bcache。

# cat /usr/lib/udev/rules.d/61-bcache.rules
....
# Backing devices: scan, symlink, register
IMPORT{program}="/sbin/blkid -o udev $tempnode"
# blkid and probe-bcache can disagree, in which case don't register
ENV{ID_FS_TYPE}=="?*", ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
...

# lsblk -o NAME,MAJ:MIN,RM,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID,PARTUUID

NAME        MAJ:MIN RM   SIZE TYPE FSTYPE MOUNTPOINT UUID                                 PARTUUID
sda           8:0    0 111.8G disk
├─sda1        8:1    0     3G part vfat   /esp       7E67-C0BB                            d39828e8-4880-4c85-9ec0-4255777aa35b
└─sda2        8:2    0 108.8G part ext2              93d22899-cd86-4815-b6d0-d72006201e75 baf812f4-9b80-42c4-b7ac-5ed0ed19be65
sdb           8:16   0 931.5G disk
└─sdb1        8:17   0 931.5G part ntfs              FAD2B75FD2B71EB7                     90c80e9d-f31a-41b4-9d4d-9b02029402b2
sdc           8:32   0   2.7T disk bcache            4bd63488-e1d7-4858-8c70-a35a5ba2c452
└─bcache1   254:1    0   2.7T disk btrfs             2ff19aaf-852e-4c58-9eee-3daecbc6a5a1
sdd           8:48   0   2.7T disk bcache            ce6de517-7538-45d6-b8c4-8546f13f76c1
└─bcache0   254:0    0   2.7T disk btrfs             2ff19aaf-852e-4c58-9eee-3daecbc6a5a1
sde           8:64   1  14.9G disk
└─sde1        8:65   1  14.9G part ext4   /          d07321b2-b67d-4daf-8022-f3307b605430 5d0a4d76-115f-4081-91ed-fb09aa2318d

在上面的例子中有一個分區之前是ext2文件系統。bcache將通過以下指令自動構建：

# make-bcache -B /dev/sdc /dev/sdd -C /dev/sda2

因為設備/dev/sdc和/dev/sdd標識了bcache文件系統，因此會在系統啟動時自動添加，而/dev/sda2則需要手動添加。在/dev/sda2偏移1024處仍殘留有之前文件系統的超級塊信息，而bcache信息是從4096偏移開始記錄，修復的方法是：

# dd if=/dev/zero count=1 bs=1024 seek=1 of=/dev/sda2

在系統重啟之後所有磁盤被正確識別：

# lsblk -o NAME,MAJ:MIN,RM,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID,PARTUUID

NAME        MAJ:MIN RM   SIZE TYPE FSTYPE MOUNTPOINT UUID                                 PARTUUID
sda           8:0    0 111.8G disk
├─sda1        8:1    0     3G part vfat   /esp       7E67-C0BB                            d39828e8-4880-4c85-9ec0-4255777aa35b
└─sda2        8:2    0 108.8G part bcache            93d22899-cd86-4815-b6d0-d72006201e75 baf812f4-9b80-42c4-b7ac-5ed0ed19be65
  ├─bcache0 254:0    0   2.7T disk btrfs             2ff19aaf-852e-4c58-9eee-3daecbc6a5a1
  └─bcache1 254:1    0   2.7T disk btrfs             2ff19aaf-852e-4c58-9eee-3daecbc6a5a1
sdb           8:16   0 931.5G disk
└─sdb1        8:17   0 931.5G part ntfs              FAD2B75FD2B71EB7                     90c80e9d-f31a-41b4-9d4d-9b02029402b2
sdc           8:32   0   2.7T disk bcache            4bd63488-e1d7-4858-8c70-a35a5ba2c452
└─bcache1   254:1    0   2.7T disk btrfs             2ff19aaf-852e-4c58-9eee-3daecbc6a5a1
sdd           8:48   0   2.7T disk bcache            ce6de517-7538-45d6-b8c4-8546f13f76c1
└─bcache0   254:0    0   2.7T disk btrfs             2ff19aaf-852e-4c58-9eee-3daecbc6a5a1
sde           8:64   1  14.9G disk
└─sde1        8:65   1  14.9G part ext4   /          d07321b2-b67d-4daf-8022-f3307b605430 5d0a4d76-115f-4081-91ed-fb09aa2318dd

同樣地，殘留超級塊還會引起類似的其他錯誤。
英文地址：http://bcache.evilpiepirate.org/