新存储结构（thin lvm）下flashcache效率测试
flashcache有两种安装方式：
1.普通的编译安装，目前似乎不支持3.x内核
2.动态内核模块编译（DMKS），这种方式相对简单，而且支持3.x高版本内核。
普通编译安装
1.首先安装必要的工具：
编译flashcache的时候需要内核头文件，这里要注意的是：
如果直接使用 yum install kernel-devel 安装的话，可能会导致 内核版本 和 内核头文件 版本不一致，在编译flashcache的时候就会出错。比如，centos6.3初装后内核版本是2.6.32-279.el6.x86_64，而直接按以上命令会安装成2.6.32-279.9.1.el6版本的头文件。
有三种方法解决这个问题：
i). 更新内核：yum update kernel（需要重启系统生效！推荐！）
ii). 直接安装和当前内核版本对应的头文件包：yum install kernel-devel-$(uname -r) （无需重启）
iii). 编译flashcache时，将头文件路径作为参数传递进去（具体看flashcache说明文档）
接下来安装各种编译软件：
yum install -y gcc gcc-c++ make autoconf cmake
安装git（flashcache托管在git上）：
yum install -y git
2.获取flashcache源文件
git clone https://github.com/facebook/flashcache.git
3.编译安装
cd flashcache
make
make install
4.安装flashcache统计脚本（可选）
复制 utils/flashstat 文件到系统程序（/usr/bin，/usr/local/bin等）目录以便查看flashcache读写情况。
DKMS安装
dkms包是放在rpmforge库里，所以首先我们需要导入 rpmforge 库：
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -i http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
yum -y install dkms
然后下载 flashcache 源文件（见面上）并进入源文件目录，执行编译安装：
make -f Makefile.dkms
make install
flashcache是一种将ssd作为缓存，普通硬盘作为后备，然后将他们合二为一作为单个整体来使用的技术。
1.选择一个未挂载的普通盘（或分区）作为后备盘。比如，/dev/sdb
注：必须保证选中的分区没有在使用中，并且未挂载在任何地方。
2.选择ssd盘，比如，/dev/sdc 作为缓存。
注：必须保证选中的ssd分区没有在使用中，并且未挂载在任何地方。
3.创建flashcache盘：
flashcache_create -p back flashcache /dev/sdc /dev/sdb
上述命令中的flashcache是盘的名字，可以任意选取。
（注：这里的名字对《flashcahce安装》中所说的flashstat脚本有影响，需要将该脚本中的cachedev替换成这里的名字）
-p 后面跟缓存的写模式，back是指回写式（write-back），与 直写式（write-through） 对应
4.为flashcache盘创建文件系统：
mkfs.ext4 /dev/mapper/flashcache
（这里使用ext4文件系统以达到更好的ssd支持。）
5.挂载创建好的flashcache盘：
mount -o discard,noatime,nobarrier /dev/mapper/flashcache /data
-o 后面接各种文件系统参数，这里的 discard,noatime,nobarrier都是为了增强flashcache盘的IO性能，虽然对文件系统的健壮性有一定损害。
6.重启系统后的操作：
默认情况下，开机是不会自动生成flashcache设备的。用
ls /dev/mapper 可以看到，没有/dev/mapper/flashcache这个设备。
这时候就要用到flashcache_load命令了：
flashcache_load /dev/sdc
然后，flashcache设备就重新生成。（注：不需要再次flashcache_create）
接下来就挂载使用了。
7. 添加启动脚本（可选）：
a) 复制flashcache源文件目录下的 utils/flashcache 脚本到 /etc/init.d 目录。
b) 加入启动项目：
chkconfig --add /etc/init.d/flashcache
另外，要注意的是一定要修改该脚本中的部分参数才能正常生效！
比如：
SSD_DISK=/dev/sdb BACKEND_DISK=/dev/sda4 CACHEDEV_NAME=flashcache MOUNTPOINT=/data FLASHCACHE_NAME=sdb+sda4
比较麻烦点的是FLASHCACHE_NAME这个变量的值，可以通过
sysctl -a | grep flashcache
判断出来。
然后是 挂载文件系统的参数（discard,noatime,nobarrier)， 需要自行添加到脚本的相应位置。
比如， 找到一行：
/bin/mount /dev/mapper/$CACHEDEV_NAME $MOUNTPOINT
修改成：
/bin/mount -o discard,noatime,nobarrier /dev/mapper/$CACHEDEV_NAME $MOUNTPOINT
flashcache性能测试
对新的存储结构做了一些测试。
以下测试结果有几点需要特别注意：
1）测试工具只是简单的 dd，都是连续读写，
2）测试是在文件系统上进行，不是裸设备
3）测试的是吞吐量（thoroughput），而不是IOPS！
4）整个物理机上只有一个DomU。这意味着瘦卷的块在物理盘上的分布是比较集中的。真实的生产环境下，瘦卷块位置通常会比较分散，因此读写速度应该会有一定下降。
5）在下面的flashcache测试中，ssd物理盘空间是非常充足的，仅使用了 5% 左右。但实际生产环境中，ssd空间使用率一般会达到70%以上，这时候ssd写性能通常会有较明显下降。
表1. 瘦卷和普通卷速度对比（底层是普通磁盘做物理卷）
|
| 瘦卷(thin lvm) | 普通卷(lvm) |
|---|---|---|
| dom0，读 | 350 ~ 360 MB/s | 390 ~ 400 MB/s |
| dom0，写 | 250 ~ 260 MB/s | 399 ~ 409 MB/s |
| domU，读 | 344 ~ 350 MB/s | 390 ~ 400 MB/s |
| domU，写 | 350 ~ 370 MB/s[1] | 390 ~ 400MB/s |
[1] 以瘦卷作为domU的磁盘时，在domU中对于已经存在的文件的覆盖写速度下降很明显：约为 100 ～ 130 MB/s。 普通卷无此现象。
表2. flashcache测试 （ssd缓存为10GB，后备盘为普通逻辑卷）
|
| flashcache做在dom0中 | flashcache做在domU中 | flashcach做在dom0，并挂载到 domU 中 |
|---|---|---|---|
| 第一次写[1] | 302 MB/s | 341 MB/s | 165 MB/s [2] |
| 第二次写 | 183 MB/s | 293 MB/s | 166 MB/s |
| 第三次写 | 206 MB/s | 265 MB/s | 169 MB/s |
| 第四次写 | 189 MB/s | 257 MB/s | 169 MB/s |
| 第一次读[1] | 160 MB/s | 150 MB/s ~ 170MB/s | 168 MB/s [2] |
| 后续读 | 370 MB/s[3] | 231 MB/s ~ 280 MB/s | 274 MB/s |
[1] 这里说的“第一次”是指 ssd 缓存为空 或者说 刚做完 flashcache 的情况。
[2] 看起来，似乎 flashcache 做好后挂到 domU，第一次和后续写是没有区别的。
[3] 通过观察可以发现不论在domU中还是dom0中，flashcache的后续读都是由ssd缓存来满足的。但是似乎domU无法使得ssd盘满载，所以导致后续读在dom0上要快于domU。
根据上表结果推测：
1.第一次写全部由ssd缓存住了，因此速度实际上是 ssd 的写速度。后面的第二，第三次测试时，由于ssd缓存已经满了，必须先清空部分缓存，回写到普通盘上，然后再将新数据写入清空的那缓存部分，所以速度有所下降。这一点可以通过在 dom0 观察 iostat 数据得到印证。
注：上述flashcache测试中，由于事先没考虑周全，所以测试是对一个 10g 多一点 的文件做读写操作，而 ssd 缓存实际上只有 10g 差点。导致io有一小部分会做 读ssd缓存->写入hdd->再写ssd 的过程。所以结果不是特别准确（比实际稍微低一点）。
2.第一次读需要首先读取普通盘上的数据，然后再写入ssd中。而且，flashcache会自动将所有读写操作都分解为4k的块，这样导致ssd的写入吞吐量较低，因此总体速度明显比较慢。而后续的读直接由缓存满足，因此相当快。