概述
在xen平台下，一般使用文件来模拟一个磁盘。在xen中使用文件来模拟磁盘有3种方式，
- blkback 直接操作
- blktap2 直接将文件映射为一个裸块设备，这样vm可以直接用phy的方式进行文件访问。
- qdisk 使用qemu来将文件模拟成一个磁盘设备。
blkback
Blkback的数据交互流程如图1所示，在Domain U 中，用户态的应用程序发出读写系
统调用，在Domain U的操作系统中的普通读写请求，被块设备前端封装成Xen格式，接着
85 通过设备通道传送给块设备后端，块设备后端将读写请求经过一系列处理后,转化为一个或
多个bio结构，submit_bio提交。前后端通过事件通道（Event Chanel）、I/O 环（I/O Ring）
以及授权表（Grant Table）完成通信和数据交互。从Domain U的角度看，块设备可以是sda、
had或者xvda 等真实设备，只是读写请求被前端截获并转交给了Domain 0。从Domain 0中
操作系统的角度看，bio最后进入 I/O 调度层，Domain U的磁盘对应着相应的磁盘镜像。
图 2 是读写请求进入在块设备后端中的详细处理过程及函数。 RING_GET_REQUEST
从I/O环中取出块设备前端发送过来的读写请求（blkif_request格式），在dispatch_rw_block_io
中将blkif_request转化成pending_req和 phys_req，最后生成一个或多个通用的bio结构，之
后的处理流程与 Linux 读写系统调用相同：bio 进入 I/O 调度层最后由真实驱动完成读写。
同时，由end_block_io_op生成响应（blkif_response）。
blkback进行文件读写
blktap2
blktap2设备比较类似于loop设备，都是通过将文件映射成一个块设备来供虚拟机使用。 在启动时，需要在xl文件中配置为
disk = ['tap2:aio:file.vhd,xvda1,w']
将文件file.vhd 模拟成一个块设备/dev/xen/blktap-2/tapdev0
IO请求从blkfront到blkback之后，通过blktap2驱动交到user space的tapdisk2进程的地址空间。然后由tapdisk2进行文件的读写。
Blktap2的数据交互流程如图2所示，DomainU中流程与blkback类似，但domain 0中
用户态的功能更加丰富了，并将原本处于内核态的部分功能移至用户态。与blkback不同是，
blktap2从设备通道中取出Domain U发送过来的读写请求（blkif_request格式），交给处于
105 用户态的 tapdisk，tapdisk 要通过对应的磁盘格式的驱动来区分磁盘镜像的类型，并且可以
选择异步IO 或者典型 IO 两种不同方式，对读写请求和数据进行检查，封装成tio结构，对
tio进行合并优化后，通过系统调用提交 tio。Blktap2 与 tapdisk通过共享内存的方式交换数
据的权限，与设备/dev/xen/blktapX 对应。blktapctr 通过设备 blktap0 管理虚拟磁盘。blktap
仍需要blkback的帮助， blktap2以及最新的blktap3已经可以独立承担块设备后端的功能
qdisk
qdisk设备是通过qemu来把文件模拟成磁盘设备。启动时在xl文件中配置为
disk = ['tap:qcow:file.vhd,xvda1,w']
IO请求从blkfront发出后，直接发送到了进程空间中qemu进程，然后由qemu进程对文件进行读写。 这样明显的减少了io路径，提高了虚拟化磁盘的性能。
注意：blktap3采用了和qdisk几乎一致的架构，用来优化blktap2。在4.4版本中，blktap3还属于开发阶段，所以这里没有提及。
性能比较
了解了2种不同访问模式原理上的区别，我对两种存储虚拟化方式进行了测试 测试平台：
| Host | cpu | Intel(R) Xeon(R) CPU E5645 @ 2.40GHz |
| Memory | 44G | |
| 硬盘 | SATA | |
| Hypervisor | Xen | 4.4.1 |
| OS | suse11 sp3 | |
| Guest | CPU | 4 |
| Memory | 4G | |
| OS | windows xp | |
| 磁盘格式 | vhd |
测试结果：
| blktap2 | qdisk | |
|---|---|---|
| Total I/Os per Send | 69.04 | 78.20 |
| Total MBs per Send | 1.08 | 1.22 |
| Average I/O Response Time(ms) | 14.48 | 12.7855 |
| Maxinum I/O Response Time(ms) | 82.48 | 93.8746 |
可以看出在qdisk模式在 IOPS、吞吐量、延迟方面均优于Blktap2。
转自：here
我在自己的设备上测试，结果与这篇文章所述一致： qdisk 的方式性能好于 blktap 的方式；而且少了一个tapdisk进程，只需要qemu-dm进程就够了。
qdisk的模式有两块关键代码： linux_gnttab_grant_map 函数，用于映射blkif protocol需要的内存； xen_blkdev_ops 结构体，实现了对img文件的操作。 上述代码都实现在qemu-xen-traditional代码里，最终编译为qemu-dm程序
xen社区负责存储性能优化的工程师的PDF：Storage-Performance-PDF.pdf
基于 Xen PVHVM 虚拟块设备的数据追踪及测试 ： pvhvm块设备的数据追踪和测试