linux控制cache使用值e,[轉]Linux塊設備加速緩存bcache和dm-cache：使用SSD來加速服務器...

在 LSFMM 2013 峰會上，Mike Snitzer, Kent Overstreet, Alasdair Kergon, 和 Darrick Wong 共同主持了一個討論，內容是關於兩個彼此獨立的塊設備層緩存方案 ——

dm-cache 和

bcache。

Snitzer 首先介紹了 3.9 kernel 引入的 dm-cache。這個方案使用率內核中的 device mapper 框架，實現了快速設備對慢速的“原始”設備的 writeback 或 writethrough 緩存。Snitzer 介紹到，dm-cache 的原理是使用 device mapper 核心，並在上面增加一個策略層。這個策略層“非常類似”一個插件接口，可以實現不同的策略。這些策略(以及緩存的內容)決定了緩存是否可以命中，是否需要進行數據遷移(在原始設備與緩存設備之間進行某個方向的數據移動)。目前已經實現了包括最近最少用(LRU)、最常使用(MFU)等策略，但目前只有缺省的“mq”策略合並到內核中了，以便減少起初需要測試到的策略數量。文件系統可以為策略提供 hints，比如某些塊臟了，或是某些塊已經被放棄了。這些信息有助於策略更好地決定塊要存儲到的位置。

之后，Overstreet 介紹了 bcache 的狀態更新，后者已經在排隊進入 3.10 了。他介紹到，bcache 已經有“很多用戶”了，而且代碼已經比較穩定了。他最近主要是在進行 bug fix。與 dm-cache 實現的的分級存儲不同，按照 Overstreet 的介紹，bcache 更像一個傳統的緩存。它可以用來存儲任何 extents，甚至是是一個扇區，而 dm-cache 只能對整塊數據進行緩存。

就在峰會開始前，Wong 給多個郵件列表(包括 dm-devel, linux-bcache, linux-kernel)發出過一封 email 來比較 bcache, dm-cache, 和 EnhanceIO。他分別編譯了帶有上述各個特性的內核，進行了一些測試。他發現，EnhanceIO 是最慢的，bcache 是它的 4-6 倍，而 dm-cache 更快，達到了 15 倍，不過 dm-cache 無法完成有些測試。所有比較都在一塊普通硬盤上進行了相同的測試，有時，由於未知的原因，dm-cache 的表現或多或少的和硬盤完全一樣。他指出，有些測試會導致 mkfs 創建的 inode table 倍緩存住，而通常這並不是一種有效的使用緩存的方法。Snitzer 表示，他曾試着去重現 Wong 的測試結果，但結果對 bcache 和 dm-cache 都得倒了更差的成績。他說他希望和 Overstreet 一起去找出原因。而 Overstreet 則表示，不應該過多地看綜合測試的成績，這些測試是游泳的，但可能帶有誤導性。

Ric Wheeler 提問，Snitzer 是否“在真實工作負載下看到了實質性的性能提升”，Snitzer提到，在不同的 Git 標簽之間進行切換就是 dm-cache 可以完勝的一個例子，不過他需要一些幫助來獲得更貼近實際使用的負載。一個參會者問道，這些方案是否假設緩存設備總是存在。Snitzer 說，dm-cache 確實如此假設，但這是需要改進的地方。Overstreet 說， bcache 並不要求 cache 設備一直都在。因為 bcache 已經在實際產品中使用了，所以它有機會去碰到這些疑難場景，並可以處理這些緩存設備無法工作的情形。Snitzer 表示，dm-cache 確實還有很多事情要做。起初，它是進行 cache 和原始設備的並行 IO，但最終不得不回到順序 IO。而且，對於流水線中有 NVM 設備的情況下，存儲層次也是如此。因為 dm “到處都是分層”，dm-cache 剛好適合進行存儲分層，不過 Overstreet 指出，bcache 也可以做到分級存儲。這個討論最終沒有一個明確的結論，只是提到需要讓兩個方案的“真實世界”性能讀數變得更好。同時也指出了，不同的測試者進行的測試得到的結論差異是巨大的，這也是真實世界的情況的一個寫照。

- See more at:

http://wangxu.me/blog/#sthash.smQmCr76.dpuf

Linux塊設備加速緩存之bcache

什么是bcache

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

同樣地，殘留超級塊還會引起類似的其他錯誤。

bcache是按照SSD特性來設計的，只按擦除桶大小進行分配，使用btree和日志混合方法來跟蹤緩存數據，緩存數據可以是桶上的任意一個扇區。bcache最大程度上減少了隨機寫的代價，它按順序填充一個桶，重新使用時只需將桶設置為無效。

bcache支持寫直達和回寫策略。回寫默認情況下是關閉的，可以在運行時改變。bcache還在最大程度上保護你的數據，在系統異常關機時數據仍然是可靠的。因為它被設計為只有在數據完全寫回存儲設備才確認寫成功。

回寫策略能夠緩存絕大多數的寫請求，然后再按照索引將臟數據按次序寫回到后端存儲設備。

SSD的特點就是隨機IO速度很快，而對於大塊順序IO的提升卻並不大。bcache會檢測順序IO並忽略；還會對每一個任務記錄動態的平均IO大小，當平均IO大小超過截止值時該任務后面的IO將會被忽略，這樣就可以透傳備份或者大文件拷貝。

在flash上發現數據IO錯誤時，首先會嘗試讀以恢復數據或者將該緩存項置為無效。對於不可恢復的錯誤，例如元數據或臟數據，bcache將會自動關閉緩存。如果有臟數據在緩存中，這時會首先關閉回寫策略然后再等待臟數據刷回。

從這里開始

首先需要安裝bcache-tools，它提供了make-bcache工具。緩存設備和后端磁盤在使用前都需要先初始化：

make-bcache -B /dev/sdb

make-bcache -C /dev/sdc

make-bcache提供了同時初始化多個設備的功能，並自動綁定緩存設備和后端磁盤：

make-bcache -B /dev/sda /dev/sdb -C /dev/sdc

bcache-tools現在已經包含了udev規則文件，bcache設備可以立即被內核感知。如果沒有udev規則，需要手動注冊設備：

echo /dev/sdb>/sys/fs/bcache/register

echo /dev/sdc >/sys/fs/bcache/register

注冊了后端磁盤后，bcache設備會出現在/dev/目錄下，現在就可以格式化然后使用了。bcache設備默認是透傳模式，因此需要綁定緩存。

bcache顯示如下：

/dev/bcache

還有(有udev規則文件時)：

/dev/bcache/by-uuid/

/dev/bcache/by-label/

如果要開始使用：

mkfs.ext4 /dev/bcache0

mount /dev/bcache0 /mnt

bcache的sysfs控制項在/sys/block/bcache/bcache。

bcache設備是按集合來管理的，但目前一個集合只支持一個bcache設備，將來會支持多個設備、元數據和臟數據鏡像。新cache設備顯示為/sys/fs/bcache/

cache綁定：

在緩存設備和后端設備都注冊之后，還要將緩存設備綁定到后端設備從而使用緩存。綁定操作如下：

echo  > /sys/block/bcache0/bcache/attach

這個操作只需要做一次就可以了。下一次系統重啟時，只需要重新注冊所有bcache設備。如果后端設備還有未定回的緩存數據，那么就不會創建/dev/bcache，直到緩存設備回來，尤其在寫回策略時特別重要。

如果需要在沒有緩存設備的時候強制使用設備：

echo 1>/sys/block/sdb/bcache/running

注意這里參數是后端設備，而不是bcache設備，何況此時bcache設備還沒有創建。如果是使用分區創建的bcache設備，例如sdb2對應的目錄是/sys/block/sdb/sdb2/bcache。

在強制使用bcache設備后，緩存設備添加到系統，這個緩存設備的所有緩存數據將會設置為無效。緩存設備的臟數據是不會繼續，因為這些臟數據將有可能使現在文件系統崩潰。

錯誤處理

bcache嘗試處理IO錯誤而不影響正常操作，但如果錯誤數超過閥值(默認是0，可配置)會關閉緩存並切換到透傳模式。

-如果是讀錯誤則嘗試直接從后端設備讀

-如果是寫直達寫錯誤，將緩存對應數據塊設置為無效

-去綁定時，刷回臟數據。臟數據寫回失敗目前是沒有處理的。

性能相關問題

bcache有很多配置選項和可調參數。默認值適合於典型配置，如果想要更好性能則需要調整相關參數。

-寫性能差

如果寫性能不理想，那么建議調到寫回策略

#echo writeback>/sys/block/bcache0/cache_mode

-性能差，或者流量並沒有緩存到SSD

默認情況下，bcache不會緩存順序IO和大文件。

打開順序IO緩存：

#echo 0>/sys/block/bcache0/bcache/sequential_cutoff

設置回默認值：

#echo 4M>/sys/block/bcache0/bcache/sequential_cutoff

-流量小，緩存不命中

現實生活中，並不是所有SSD都能提供足夠快的速度作為磁盤的緩存，特別一個SSD作為多塊磁盤的緩存，或者順序IO時。所以需要避免SSD成為系統瓶頸。

為了避免bcache設備因為SSD變慢，當延遲超過閥值時逐漸減少流量。需要關閉擁塞控制項：

#echo 0>/sys/fs/bcache//congested_read_threshold_us

#echo 0 >/sys/fs/bcache//congested_write_threshold_us

對於讀，默認值是2000us(2ms)，對於寫是20000.

SYSFS - 后端設備

/sys/block//bcache, /sys/block/bcache*/bcache, /sys/fs/bcache//bdev*

SYSFS - 緩存集合

/sys/fs/bcache/

SYSFS - 緩存設備

/sys/block//bcache

英文：Documentation/bcache.txt

使用 LVM (基於dm-cache) 新的緩存特性

如果你有一台帶有慢速硬盤和快速SSD的電腦，你想使用SSD作為快速持久緩存用來提升訪問硬盤的速度。然而直到最近，你有三個選擇：bcache和dm-cache都upstream，或者Flashcache/EnhanceIO。Flashcache不是upstream。dm-cache要求你首先坐下來，使用計算器計算塊的偏移。bcache是三個選擇中最全面的。

但是最近LVM已經增減了緩存的支持(構建在dm-cache之上)，因此在理論上，你能讓已存在的邏輯卷轉換到已緩存的設備。

安裝

為了在實踐中了解是怎樣工作的，我在以前的無盤虛擬群集中添加了3塊硬盤。

在鏡像配置中有兩個2TB的WD硬盤。通過藍色(冷)線連接。在左側是三星EVO 250GB SSD，作為緩存的紅色(熱)盤。

另一個新聞：哦，現在品牌制造商的SSD是真的便宜！

lsblk輸出如下,sda和sdb是WD硬盤，sdc是三星SSD:

性能

在創建 緩存之前，先看看硬盤的速率如何.  以下數據包含了 ext4 和 LVM overhead (ie. 體現在文件系統里，並非塊存儲). 我還用了 O_DIRECT.

HDD writes: 114 MBytes/sec HDD reads: 138 MBytes/sec SSD writes: 157 MBytes/sec SSD reads: 197 MBytes/sec

這些數字並沒有體現出SSDs的好處 — 就是隨機訪問硬盤時，性能沒有什么區別.

Terminology

lvmcache(7) [沒有什么能拷貝的地方] 文檔指出了一些用到的術語:

創建 LVs

文檔中很誇張的提到，移除錯誤的 LV 將會完全顛覆之前的 OriginLV, 為了測試這一特性我 在有幾個鏡像文件的慢速HDDs上創建了一個 OriginLV:

需要注意的是resizing cached LVs功能目前並未提供 (可能以后出來 — 現在只能先移除緩存，從新分配大小再重新創建緩存).

創建緩存層

從文件的角度來說,這並不明確,但是一切都必須在一個簡單的卷組中.也就是說，你必須創建一個既包括慢速和快速的磁盤卷組 - 它並不是簡單工作。

因此，我的第一個步驟是擴大我現有的VG ，包括快盤：

我創建了快速的SSD兩個LVs 。一個是CacheDataLV ，這就是緩存發生。另一個是用於存儲被高速緩存在CacheDataLV的數據塊的索引的CacheMetaLV 。該文件說， CacheMetaLV應該是千分之一的CacheDataLV的大小，但最少為8MB 。由於我的總可用空間快是232GB ，而我希望有一個1000:1的分裂，我大方的選擇一個1GB的CacheMetaLV ， 229G的CacheDataLV ，而且會留下一些遺留下來的空間(我最終的分割結果是229:1 ) 。

(你會發現，我的緩存大於我的測試OriginLV ，但是這很好，因為一旦我已經制定了所有的陷阱，我真正的OriginLV將超過1 TB).

為什么要在PV上留下2.88GB的空間?我也不太清楚，只是第一次使用時，我並沒有預留空間，結果執行 lvconvert命令后 [如下] 提示需要1GB的擴展空間。

把 CacheDataLV和CacheMetaLV 放到“緩存池”里 :

接着把緩存池連到OriginLV來創建最終的緩存工程:

結果

看起來還不錯? 在使用緩存 LV后，得到的數據如下:

LV-cache writes: 114 MBytes/sec LV-cache reads: 138 MBytes/sec

和原來硬盤的結果一致.

接下來我會創建一些請求，然后看看他們的性能如何 (就是剛才我提到的問題).