深入分析QEMU cache——虚拟机迁移需要注意writeback方式会造成数据丢失。

Cache 的一些基本概念

Cache 最先指的是高速缓存, 用于平衡 CPU 和内存之间的速度, 后来, 进一步发展为 一种技术, 用在速度相差较大的两种硬件之间, 用于协调两者数据传输速度差异的结构.

本文主要指的是协调内存和硬盘速度的 Cache.

在 Cache 和他的后端存储的数据同步一般有以下几种方式:

• Write through: 数据一旦在 Cache 中, 就马上同步到真实设备中, 也就是保持同步
• Write back: 见闻知意思, writeback 的意思就是数据一旦在 Cache 中, 这个操作就算完成了, 并不需要马上同步到真实设备中, 除非用户手动指定(fsync), 或者此 Cache 中得内容发生了改变

 

QEMU 中的 Cache 模型

由于虚拟化的关系, QEMU 中的 Cache 模型有一点复杂.

在虚拟化的世界中, 一个对象通常有两端, guest 端和 host 端, 或者称为 frontend 和 backend. 比如 vcpu 对象, 在 frontend 是一个 CPU, 在 backend 端, 它只是 一个线程, 对磁盘来讲, frontend 端看到 的是一个磁盘设备, 在 backend 端, 仅仅 是一个普通的文件而已.

所以 QEMU 中的 Cache, 就有两种情况, guest(frontend) 看到的 disk 的 Cache, 和 host(backend)看到的那个普通文件的 Cache. QEMU 需要对前者进行模拟, 对后者 需要管理. 后面会用代码详细解释 QEMU 是怎么实现的.

先遍历一下 QEMU 中 Cache 模式:

none	off	on
writethrough	on	off
writeback	on	on
unsafe	on	ignore
directsync	off	off
Cache Mode	Host Cache	Guest Disk Cache

 

 

实现的代码分析

为了方便, 我选择使用 ide 的 device 和 raw 的磁盘格式.

 

host end 初始化 block 的流程

根据上面所说的, 模拟磁盘的初始化分为前端(磁盘设备)和后端(镜像文件)的初始化, 在后端的初始化中, 入口函数是 drive_init(), 到最后的 qemu_open() 终止. 上图 中红色得模块就是 Cache 初始化最重要的两个地方.

简单的分析一下流程.

int bdrv_parse_cache_flags(const char *mode, int *flags) { *flags &= ~BDRV_O_CACHE_MASK;   /* * - BDRV_O_NOCACHE: host end 绕过 cache * - BDRV_O_CACHE_WB: guest 的磁盘设备启用 writeback cache * - BDRV_O_NO_FLUSH: 在 host end 永远不要把 cache 里的数据同步到文件里 * 这几个宏的具体应用后面分析到数据读写的时候会进行分析 */ if (!strcmp(mode, "off") || !strcmp(mode, "none")) { /* 由上, 这个组合表示的是 host end 不用 Cache, 数据直接在用户空间(QEMU) * 和真实设备之间通过 DMA 直接传输, 但是同时, 告诉 guest 模拟的磁盘设备 * 是有 cache 的, guest 能发起 flush 的操作(fsync/fdatasync) */ *flags |= BDRV_O_NOCACHE | BDRV_O_CACHE_WB; } else if (!strcmp(mode, "directsync")) { /* 很好理解, 完全没有 cache, host end 和 guest end 都没有 cache, guest * 不会发起 flush 的操作 */ *flags |= BDRV_O_NOCACHE; } else if (!strcmp(mode, "writeback")) { /* 和上面相反, host side 和 guest side 都有 cache, 性能最好, 但是如果 * host 掉电, 会导致数据的损失 */ *flags |= BDRV_O_CACHE_WB; } else if (!strcmp(mode, "unsafe")) { /* 见文可知意, 最不安全的模式, guest side 有cache, 但是 host side 不理睬 * guest 发起的 flush 操作, 完全忽略, 这种情况性能最高, snapshot 默认使用 * 的就是这种模式 */ *flags |= BDRV_O_CACHE_WB; *flags |= BDRV_O_NO_FLUSH; } else if (!strcmp(mode, "writethrough")) { /* host end 有 cache, guest 没有 cache, 其实通过后面的代码分析可以知道, * 这种模式其实是 writeback + flush 的组合, 也就是每次写操作同时触发 * 一个 host flush 的操作, 会带来一定的性能损失, 尤其是非 raw(e.g. qcow2) * 的网络存储(e.g. ceph), 但是很遗憾, 这是 QEMU 默认的 Cache 模式 */ /* this is the default */ } else { return -1; }   return 0; }  
DriveInfo *drive_init(QemuOpts *all_opts, BlockInterfaceType block_default_type) { /* code snippet */  
    value = qemu_opt_get(all_opts, "cache"); if (value) { int flags = 0;   /* 解析命令行 -drive 的 cache= 选项 */ if (bdrv_parse_cache_flags(value, &flags) != 0) { error_report("invalid cache option"); return NULL; }   /* Specific options take precedence */ if (!qemu_opt_get(all_opts, "cache.writeback")) { qemu_opt_set_bool(all_opts, "cache.writeback", !!(flags & BDRV_O_CACHE_WB)); } if (!qemu_opt_get(all_opts, "cache.direct")) { qemu_opt_set_bool(all_opts, "cache.direct", !!(flags & BDRV_O_NOCACHE)); } if (!qemu_opt_get(all_opts, "cache.no-flush")) { qemu_opt_set_bool(all_opts, "cache.no-flush", !!(flags & BDRV_O_NO_FLUSH)); } qemu_opt_unset(all_opts, "cache"); }   return blockdev_init(all_opts, block_default_type); }

接下来的流程稍微复杂一点:

blockdev_init
  -> bdrv_open
    -> bdrv_file_open
      -> raw_open
        -> raw_open_common
          -> raw_parse_flags
          -> qemu_open

首先是从 blockdev_init 到 raw_open 的流程, 简单分析如下:

static DriveInfo *blockdev_init(QemuOpts *all_opts, BlockInterfaceType block_default_type) { DriveInfo *dinfo;   /* code snippet 解析和配置各种各样的参数, e.g. 磁盘格式, 启动顺序等等, * 最后填充到 dinfo 对象中 */  
    snapshot = qemu_opt_get_bool(opts, "snapshot", 0);  
    file = qemu_opt_get(opts, "file");   if (qemu_opt_get_bool(opts, "cache.writeback", true)) { bdrv_flags |= BDRV_O_CACHE_WB; } if (qemu_opt_get_bool(opts, "cache.direct", false)) { bdrv_flags |= BDRV_O_NOCACHE; } if (qemu_opt_get_bool(opts, "cache.no-flush", false)) { bdrv_flags |= BDRV_O_NO_FLUSH; }   if (snapshot) { /* 前面讲过, snapshot 打开磁盘时候, 使用 unsafe 的 cache 模式 */ bdrv_flags &= ~BDRV_O_CACHE_MASK; bdrv_flags |= (BDRV_O_SNAPSHOT|BDRV_O_CACHE_WB|BDRV_O_NO_FLUSH); }  
    bdrv_flags |= ro ? 0 : BDRV_O_RDWR;   /* 使用 bdrv_open 打开文件 */ ret = bdrv_open(dinfo->bdrv, file, bs_opts, bdrv_flags, drv, &error);   /* 返回配置好的 DriveInfo *dinfo, 这个对象在初始化模拟磁盘设备 * 的时候被传入, 写入该磁盘设备的 PCI config space */ return dinfo; }   int bdrv_open(BlockDriverState *bs, const char *filename, QDict *options, int flags, BlockDriver *drv, Error **errp) { BlockDriverState *file = NULL; const char *drvname;   /* 打开文件, QEMU 支持的镜像格式都有一个后端的 format, 比如 raw 和 * qcow2 这个 format 就是 file, 其他的还有 sheepdog, glusterfs 的 * gluster 等. 所以这里其实是打开一个本地文件 */ ret = bdrv_file_open(&file, filename, file_options, bdrv_open_flags(bs, flags | BDRV_O_UNMAP), &local_err);   /* 其实 bdrv_file_open() 就会调用 bdrv_open_common 函数, 只不过那个时候调用 * bdrv_open_common() 用的是 file 这个 BlockDriver, 现在是直接磁盘文件的 * format 的 BlockDriver(qcow2, raw 等), 所以这里的函数是来初始化特定格式的 * 磁盘文件, 如 qcow2_open 等 */ ret = bdrv_open_common(bs, file, options, flags, drv, &local_err); }   int bdrv_file_open(BlockDriverState **pbs, const char *filename, QDict *options, int flags, Error **errp) { BlockDriverState *bs;   /* 找到相应的格式的 BlockDriver, 由于这里是 file 的 open, 因为 file * 来没有被打开, 所以这里第二个指针传递的是空, 注意 drv 这个参数, 表示 * file 的 BlockDriver */ ret = bdrv_open_common(bs, NULL, options, flags, drv, &local_err);   return ret; }   static int bdrv_open_common(BlockDriverState *bs, BlockDriverState *file, QDict *options, int flags, BlockDriver *drv, Error **errp) { bs->open_flags = flags;  
    open_flags = bdrv_open_flags(bs, flags);   /* 注意这里, flags 保存着之前 bdrv_parse_cache_flags 获取到的 flags, * 如果用户没有指定 none, writeback, 或者是 unsafe, 那么 guest 看到 * 的这个磁盘设备是没有 cache 的, 后面我会以 hdparm 这个工具来验证, * 同时, 这个变量(bs->enable_write_cache)控制着 QEMU 怎么模拟 cache * 行为, 后面写文件的时候会分析到 */ bs->enable_write_cache = !!(flags & BDRV_O_CACHE_WB);   /* 打开文件, 因为从上面的流程可以看到, 这里作为 file 打开, 而不是 * 作为 image format(e.g. qcow2) 打开, 所以这里调用的是 bdrv_file_open() * 方法, 也就是 raw-posix.c 中 format_name="file" 的 BlockDriver 里面的 * 的 raw_open */ if (drv->bdrv_file_open) { assert(file == NULL); assert(drv->bdrv_parse_filename || filename != NULL); ret = drv->bdrv_file_open(bs, options, open_flags, &local_err); } else { if (file == NULL) { error_setg(errp, "Can't use '%s' as a block driver for the " "protocol level", drv->format_name); ret = -EINVAL; goto free_and_fail; } bs->file = file; ret = drv->bdrv_open(bs, options, open_flags, &local_err); }   return ret; }

最后剩下核心的 raw_open 函数, 这个函数和 host side 的 Cache 相关, 通过上面 的分析, 已经比较简单了.

/* 这个函数其实是 raw_open_common */ static int raw_open(BlockDriverState *bs, QDict *options, int flags, Error **errp) { BDRVRawState *s = bs->opaque;  
    s->type = FTYPE_FILE; return raw_open_common(bs, options, flags, 0); }   static int raw_open_common(BlockDriverState *bs, QDict *options, int bdrv_flags, int open_flags) { s->open_flags = open_flags; /* 解析 open 的参数, 把 QEMU 的 BDRV_O_* 映射成 open 的 O_*, 下面详细分析 */ raw_parse_flags(bdrv_flags, &s->open_flags);  
    s->fd = -1;   /* 用上面解析到得参数打开文件 */ fd = qemu_open(filename, s->open_flags, 0644); s->fd = fd; }   static void raw_parse_flags(int bdrv_flags, int *open_flags) { assert(open_flags != NULL);   /* 首先清空其他标志 */ *open_flags |= O_BINARY; *open_flags &= ~O_ACCMODE; /* 设置读写权限位 */ if (bdrv_flags & BDRV_O_RDWR) { *open_flags |= O_RDWR; } else { *open_flags |= O_RDONLY; }   /* 如果设置了 cache=none, 那么直接用 O_DIRECT 打开文件, 这个标志保证数据 * 的传输将不会通过内核空间, 而是使用 DMA 直接在用户空间到存储设备之间 * 传送, 不保证数据是否同步. 这就是 cache=none 的由来 */ if ((bdrv_flags & BDRV_O_NOCACHE)) { *open_flags |= O_DIRECT; } }

 

guest end cache 的设置

在上面的的 bdrv_open_common() 函数中, 会设置 BlockDriverState->enable_write_cache 成员, 这个成员表示 guest 默认是否启用 writeback 的 Cache. 接下来会看到, guest 获取设备寄存器的时候, 会相应地用这个值填充寄存器的位, 下面以 IDE 硬盘来做例子.

guest 在初始访问 IDE 设备时, 会发送 IDENTIFY DRIVE (0xec) 指令, 设备收到这个 指令后, 需要返回一个 512 字节的信息, 包括设备的状态, 扇区数目, 等等的信息.

static void ide_identify(IDEState *s) { uint16_t *p; unsigned int oldsize; IDEDevice *dev = s->unit ? s->bus->slave : s->bus->master;  
    memset(s->io_buffer, 0, 512); p = (uint16_t *)s->io_buffer;   /* 看这里, bit 85 表示 writeback Cache 的状态, cache=none 之类的模式 * 是会设置这个位的, 这样, guest 会发 fsync 指令过来, 否则, geust * 不会自动发送 fsync 同步数据, 当然, guest 可以在稍后设置是否启用 * writeabck cache, QEMU 的新版本已经支持这个功能了. */ /* 14 = NOP supported, 5=WCACHE enabled, 0=SMART feature set enabled */ if (bdrv_enable_write_cache(s->bs)) put_le16(p + 85, (1 << 14) | (1 << 5) | 1); else put_le16(p + 85, (1 << 14) | 1);  
    memcpy(s->identify_data, p, sizeof(s->identify_data)); s->identify_set = 1; }

 

 

Cache 的工作模式

首先简单分析一下 guest 到 QEMU 的 I/O 执行路径:  下面的函数 bdrv_co_do_writev(bdrv_co_do_rw), 很好的阐释了 QEMU 怎么模拟 磁盘的 cache

static int coroutine_fn bdrv_co_do_writev(BlockDriverState *bs, int64_t sector_num, int nb_sectors, QEMUIOVector *qiov, BdrvRequestFlags flags) { if (ret < 0) { /* Do nothing, write notifier decided to fail this request */ } else if (flags & BDRV_REQ_ZERO_WRITE) { ret = bdrv_co_do_write_zeroes(bs, sector_num, nb_sectors); } else { ret = drv->bdrv_co_writev(bs, sector_num, nb_sectors, qiov); }   /* enable_write_cache 为 false, 即 cache=writethrough或者directsync, 那么 * 每次写完都执行一次 flush 操作, 保证数据的同步, 当然, 这样会损失很大的性能 */ if (ret == 0 && !bs->enable_write_cache) { ret = bdrv_co_flush(bs); }   return ret; }   int coroutine_fn bdrv_co_flush(BlockDriverState *bs) { int ret;   /* 对于 unsafe 的cache, 任何时候都不需要把数据真正同步到磁盘 */ if (bs->open_flags & BDRV_O_NO_FLUSH) { goto flush_parent; }  
    BLKDBG_EVENT(bs->file, BLKDBG_FLUSH_TO_DISK); if (bs->drv->bdrv_co_flush_to_disk) { ret = bs->drv->bdrv_co_flush_to_disk(bs); } else if (bs->drv->bdrv_aio_flush) { BlockDriverAIOCB *acb; CoroutineIOCompletion co = { .coroutine = qemu_coroutine_self(), };  
        acb = bs->drv->bdrv_aio_flush(bs, bdrv_co_io_em_complete, &co); if (acb == NULL) { ret = -EIO; } else { qemu_coroutine_yield(); ret = co.ret; } }  
flush_parent: return bdrv_co_flush(bs->file); }

那么对于 guest side, 如果磁盘有 cache, 那么 guest 是如何保证同步到磁盘上的:

guest 会根据磁盘的 cache 情况指定相应的调度策略, 来把数据从内存同步到磁盘 中, 或者用户手动指定 fsync, 这时也会发生 flush.

关于刷新的机制, 没有什么好说的, 无非就是调用系统调用 fdatasync, 如果系统不支持 fdatasync, 那么调用 fsync.

# hdparm -I /dev/sdb Commands/features:
        Enabled Supported: * SMART feature set * Write cache * NOP cmd * 48-bit Address feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT # hdparm -I /dev/sdc Commands/features:
        Enabled Supported: * SMART feature set Write cache * NOP cmd * 48-bit Address feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT

 

 

 

测试

使用 ubuntu-13.04 server 版本, 内核版本号 3.8.0-19. 24 cores, 20GB的 memory.

PS: 这里只是针对行的比较几种 cache 模式的性能, 不能作为专业的测试结果.

FIO 配置:

[test]
rw=rw
rwmixread=50
ioengine=libaio
iodepth=1
direct=1
bs=4k
filename=/dev/sdb
runtime=180
group_reporting=1

none	293/235/218/200/200	292/234/215/199/200
writethrough	5/36/72/93/113	5/35/73/93/113
writeback	1896/1973/1944/1627/2027	1894/1979/1947/1627/2023
Cache Mode	Read IOPS	Write IOPS

writethough 的性能相当糟糕, 写的性能我还能理解, 读的性能完全不能理解, 仔细 想了一下, 应该是”混合读写”导致的, “写”拖慢了”读”, 我随后单独做了一个随机读 的测试, IOPS 达到 四千多, 这次应该是正常的.

结论

通过以上的分析, writethrough 的性能很差, 因为它几乎相当于 writeback + flush, writeback 的性能最好, 但是在掉电/迁移的情况下不能保证数据安全, none 的读性能 很差, 因为他完全绕过了 kernel 的 buffer.

总的来说, 选择 cache 模式的时候, 至少要考虑以下几种情况:

• 你的存储是本地还是分布式的, 具体是那种存储, 支不支持 Direct IO(FUSE?), 一般来说网络文件系统使用 writethrough cache 性能很糟糕
• 是否需要迁移, 有的 cache 模式迁移会导致数据丢失.