LVM 创建的快照 INPUT 性能损失太大，不知各位有没有更好的解决方案？

[extreme]

新年快乐。

由于需要对某些东西进行测试，为了方便，先在一个LV中部署好环境(这里叫LV1吧)，通过lvcreate的snapshot功能创建另一个LV(LV2)，因此下一次测试时，直接删掉LV2，使用lvcrease以LV1为源再创建一个新的LV。

这样操作非常方便，但我发现，随着快照数目的增加，LV1的I/O性能越来越差，LV2, LV3等更是惨不忍睹。

对于无快照的LV，使用dd，INPUT可以在500 Mbytes/s上下浮动，但增加一个快照后，原LV的INPUT性能就折半了，快照LV的INPUT更是只有数十Mbytes/s……

看了下相关文档，快照功能使用的是Copy-and-Write技术，读可以直接从原数据中读取，但写操作并不简单……

把chunksize设置得大一些，虽然INPUT性能提升较大，但相对无LV状态来说，损失还是有十倍之多。

“鸡肋”这次在这里形容COW真是最合适不过了。

ploop有提供快照功能，不过好像并不能多个快照一起使用。

不知各位有没有更好的解决方案？

感激不尽。

不小心写错了，应该是Copy-On-Write，而不是Copy-and-Write。

想起了QCOW2有快照功能，看了一篇文章，发现有一个“backing_file”参数，于是使用“backing_file”参数，以LV1为基础创建了一个QCOW2文件。经测试，对LV1的INPUT性能影响极小，QCOW2文件的INPUT性能比快照LV的性能高，但仍然低下。

经过几乎一个下午的测试，得出了二楼的解决方案。

[zjgood]

先收藏，坐等回复，顺带帮顶。

[extreme]

目前的解决方案是：
在LV1中创建卷组，以及LV(LV-INSIDELVM)，在LV-INSIDELVM中部署环境。
使用QCOW2的backing_file参数创建QCOW2的虚拟磁盘文件，另外使用LVCREATE创建一个比QCOW2虚拟磁盘文件大的普通的LV(LV-FOR-QCOW2)。
使用backing_file的QCOW2 IO虽然低下，但比使用LVM创建的快照好，并且貌似不会对LV-INSIDELVM的性能产生太大(可能是无影响，性能与未做快照前相当，当然这里还不能下结论)的影响。

由于使用了backing_file，因此QCOW2虚拟磁盘文件中会有一个一模一样的LV-INSIDELVM，把LV-FOR-QCOW2加入到QCOW2虚拟磁盘文件的卷组中，再resize LV和分区。

由于LV-FOR-QCOW2是非快照，亦未被快照，因此INPUT/OUTPUT性能优越，加入QCOW2虚拟磁盘文件的VG中后，可以让写入QCOW2虚拟磁盘文件的数据写入到该LV中，因此实现了INPUT/OUTPUT性能的优化。

以下是测试结果：
未使用LV-FOR-QCOW2：
root@debian:~# dd if=/dev/zero of=/mnt/qcow2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 9.52313 s, 110 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/qcow2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 13.4839 s, 77.8 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/qcow2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 8.42614 s, 124 MB/s

LV-FOR-QCOW2的性能：
root@debian:~# dd if=/dev/zero of=/mnt/LV-FOR-QCOW2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 2.94569 s, 356 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/LV-FOR-QCOW2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.60771 s, 652 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/LV-FOR-QCOW2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.52536 s, 687 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/LV-FOR-QCOW2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.50046 s, 699 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/LV-FOR-QCOW2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.56133 s, 672 MB/s

使用LV-FOR-QCOW2扩充后的性能：
root@debian:~# dd if=/dev/zero of=/mnt/qcow2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.71546 s, 611 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/qcow2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.52238 s, 689 MB/s
root@debian:~# dd if=/dev/zero of=/mnt/qcow2/test bs=4k count=256000 conv=fdatasync
256000+0 records in
256000+0 records out
1048576000 bytes (1.0 GB) copied, 1.51794 s, 691 MB/s

[kaneg]

Cow,顾名思义，是最大照顾读操作而做的权衡，而要读写都高性能就是鱼与熊掌不可兼得